Automated generation of an english language representation of a formal network security policy

ABSTRACT

A system and method for generating a human readable, e.g. English language, description of a formal specification of network security policy that allows non-technical staff within a user&#39;s organization to comprehend the policy. The description is simple enough to be understood, yet captures salient details of the policy.

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application is a Continuation in Part to U.S. Ser. No.09/479,781 filed Jan. 7, 2000 (Attorney Docket No. KROL0003) and claimspriority to U.S. Ser. No. 60/212,126 filed Jun. 16, 2000 (AttorneyDocket No. SECU0001PR).

BACKGROUND OF THE INVENTION

[0002] 1. Technical Field

[0003] The invention relates to security and network services. Moreparticularly, the invention relates to a system and methods forgenerating an English language description of a formal specification ofnetwork security policy that allows non-technical staff within a user'sorganization to comprehend the policy.

[0004] 2. Description of the Prior Art

[0005] Networked information systems are an essential part of manyorganizations. Critical systems, services, and information resources allrequire protection that depends on effective orchestration of a varietyof factors: network architecture, security products, site security,administrative procedures, end user responsibility, and more. A networksecurity policy is an explicit plan of how to accomplish thismulti-faceted protection, what objectives the plans should meet, andwhat assets are being protected.

[0006] To manage a network, an end user needs to know and understandwhat is happening on the network. Most security holes come fromunexpected, misconfigured, or unauthorized services, for example, from ahigh-port telnet, a new service added in, a rogue server, and/or amisconfigured workstation. The end user does not know what is theunauthorized network traffic.

[0007] Security administrators need tools to help them formulate sitesecurity policy and to translate the policy into monitoring andenforcement mechanisms. They need to be sure that the computer enforcedpolicy—often cobbled together from a plethora of disjoint access controlmechanisms—matches their enterprise policy, all too often specified in aloose natural language or a set of unwritten principles. This leads toconfusion as to why access is being granted or denied to particularresources and may lead to unintentional breaches of security.

[0008] In addition to monitoring network system traffic, it is importantfor network analysts to assess their network's configuration. Adiscussion on current techniques for network assessment follows below.

[0009] A conventional network assessment visit determines the customernetwork using the following information:

[0010] 1) Network security scanning technology, e.g. port orvulnerability scans;

[0011] 2) Customer interviews;

[0012] 3) Inspection of customer log files, perhaps using machineaggregation and filtering; and

[0013] 4) Occasionally, inspection of customer log files and networktraffic.

[0014] As a matter of practicality, the information is typically derivedfrom the first three of these items. Customer log files and networktraffic is of a volume so great that it is impractical to examine it ina short assessment visit.

[0015] The weaknesses such conventional methods are as follows:

[0016] Vulnerability Scans

[0017] Network vulnerability scanners only detect certain types of knownvulnerabilities. Such vulnerabilities are generally not detecteddirectly, but are inferred based on host responses to a series ofnetwork packets sent to hosts by the scanner. This process does notdirectly ensure that data traffic on the subject network matchesexpectations, either explicit or implicit.

[0018] Network vulnerability scanners cannot see a host if it does notrespond to packets. A host that is only a source of network packets,such as, for example, a rogue router, is not visible to a scanner. Hostswhich are turned off or otherwise temporarily disconnected, such as, forexample, workstations and laptops, are often missed by vulnerabilityscanners. This problem is compounded by the fact that scans are oftenscheduled for non-work hours in order to alleviate customer fears thatthe scans will somehow impact production systems and organizationalmission.

[0019] Network scanners typically return a large volume of vulnerabilityinformation, based on all possible configured elements in a network. Thescanner tools cannot currently interpret those vulnerabilities in lightof business requirements which the subject systems are intended tosupport, or even for the specific network architecture of which thosesystems are a part. The scan results must be reviewed manually by asecurity analyst, who applies a knowledge of the business requirementsand network architecture to an interpretation of those results. Suchmanual process is error-prone because the volume is so great thatproblems may be overlooked.

[0020] Another problem is that the scan derives only vulnerabilities,not network usage patterns. Therefore, the scan cannot detect securityproblems that are attributable to human behavior, but only those scansthat result from misconfigured systems and/or systems which havedocumented design problems.

[0021] Network scanners cannot diagnose incorrect client usage ofsoftware. For example, network scanners cannot detect whether webservers are being used with invalid ciphersuites, whether 40-bitbrowsers are in use, and whether a given telnet port is accessed only bya management station.

[0022] Network scanners must be targeted to particular subnets. If acustomer has forgotten to mention a subnet, the scanner does not noticeit.

[0023] Customer Interviews

[0024] Customers may not provide the network analyst complete oraccurate information, either because the customer forgot details,because the information is not known to the customer, or because thecustomer does not understand the importance of giving the information tothe analyst.

[0025] Customer interviews at best can provide descriptions of overtusage of subject systems, and generally not covert usage. Often, formalpolicies of the organization are not even documented, much lesspromulgated, audited and enforced.

[0026] Hidden agendas, office politics, and other factors also canaffect the success of the interview process.

[0027] Host Inspection

[0028] Inspecting host configuration files is a time consuming, manualprocess that is subject to human error. In the assessment of any largenetwork, it is impractical to include an inspection of theconfigurations for more than a few critical systems.

[0029] Once again, inspection of host configurations does not revealcompletely intended usage of the subject systems. The configurationsmust be analyzed within the context of the business requirements andoverall security environment of the organization. This manual process isvery human dependent and prone to error.

[0030] Log File Inspection

[0031] Log file inspection can provide great insight into the workingsof network components. Machine-based aggregation and filtering systemscan speed this process. However, logs provide only a components' ownview of its status. If a component is misconfigured, the log data fromthe component cannot be trusted. Log data may also be subject tomodification by an attacker who has penetrated the machine and isseeking to mask his presence.

[0032] In addition, because log aggregation systems work in cooperationwith the components that generate the information, they requireconfiguration changes to every component that they examine. Also, theyare unable to detect when a component is added to the system.

[0033] Such techniques of performing network assessments generally arelimited in their ability to determine actual security threats toinformation systems. Generally, they represent the state of the art andare indicative of best practices within the security community today.

[0034] A way to reduce or eliminate the confusion described above is byproviding a user-friendly and, yet, rigorous way of specifying securitypolicy, as well as providing tools for monitoring and enforcing thesecurity policy.

[0035] It would be advantageous for a network policy to provide thedefinition of normal traffic on the network.

[0036] It would be advantageous to provide a monitoring mechanism thatlets an end user determine and understand traffic and/or activity on anetwork.

[0037] It would be advantageous to provide methods and system that, whengiven known network characteristics, thereby spots intruder access, andtrack changes to a network.

[0038] It would be advantageous to provide a policy generator tool thatassists an end user in generating security policy for a network.

[0039] It would be advantageous to provide a tool that automaticallyconverts a network security policy into English language representation.

[0040] It would be advantageous to provide a tool that allows an enduser to query network traffic data.

[0041] It would be advantageous to provide a technique for transmittingan event description of network traffic from a source file or datastream to a target destination, such as a network policy engine.

SUMMARY OF THE INVENTION

[0042] The invention is a network security policy monitoring system andmethod that comprises supportive features, algorithms, and tools. It isideally suited for network and security assessments or long-termmonitoring where real network traffic is analyzed to identify abnormaltraffic patterns, system vulnerabilities, and incorrect configuration ofcomputer systems on the network. The invention listens on a network,logs events, and takes action, all in accordance with a rule basedsystem-wide policy. The invention provides a technique that is able toincorporate external sources of event information, such as are generatedin log files of other network components. The inventive technique getsprotocol information, which can make it more meaningful to a networkadministrator. It sends data upstream to an event log and interprets thedata. It listens to secure protocols and can identify encryption qualityof service parameters. It extracts basic security parameters, such as,for example, network events, and passes them to a policy managercomponent.

[0043] The policy manager component implements system-wide policies,based on monitored system or enterprise traffic. The policy managercomponent provides a trust manager that takes as its input a securitypolicy defined as a set of policy rules and a set of credentials, andthat is capable of processing requests for trust decisions, i.e.evaluating compliance with the policy. Unlike other trust managementsystems, the invention is designed to be a passive monitor of networktraffic. As such, it need not be installed on target hosts or integratedinto existing applications.

[0044] Two key aspects of the policy manager component are provided. Oneaspect is a unified view of the interaction between two principalsacross a stack of protocol areas, each area covered by discrete policyrules. The final trust decision applied is based on policy rules thatbetter fit the entire interaction. The second aspect comprises thepolicy manager's policy definition language that supports the monitoringand auditing of a network's activity in addition to traditionalaccess/denial authorization decisions.

[0045] The policy definition language is described in A DeclarativeLanguage for Specifying A Security U.S. patent application Ser. No.09/479,781, (Jan. 7, 2000). The policy definition language is discussedherein to the extent necessary to explain such language to those skilledin the art in connection with the invention disclosed herein. Thedeclarative language system comprises a language as a tool forexpressing network security policy in a formalized way. It allows thespecification of security policy across a wide variety of networkinglayers and protocols. Using the language, a security administratorassigns a disposition to each and every network event that can occur ina data communications network. The event's disposition determineswhether the event is allowed, i.e. conforms to the specified policy ordisallowed and what action, if any, should be taken by a system monitorin response to that event. Possible actions include, for example,logging the information into a database, notifying a human operator, anddisrupting the offending network traffic. Further details of the policydefinition language can be found in the patent application cited hereinabove.

[0046] Unlike Intrusion Detection Systems (IDS) systems, which look forthe signatures of known attacks, the invention herein is focused ondefining allowed traffic patterns and how to handle events that deviatefrom those patterns.

[0047] The invention comprises, but is not limited to, six majorfeatures and tools. The first feature discussed is auto-conversion ofpolicy language, whereby policy language is converted to an Englishlanguage representation. Next, an algorithm for efficient ruleevaluation is provided. Then, a credential/assertion optimizationtechnique is provided. A policy generator tool is provided. Anembodiment in which the invention is used as an assessment tool isprovided. Finally, a technique for secure sensitive event extractionfrom protocol monitoring is provided.

BRIEF DESCRIPTION OF THE DRAWINGS

[0048]FIG. 1a is a schematic diagram of components of the systemaccording to the invention;

[0049]FIG. 1b is a schematic diagram of components of the systemaccording to the invention;

[0050]FIG. 2 is a high level workflow flow diagram according to theinvention;

[0051]FIG. 3 is an example of a policy wizard dialog box according tothe invention;

[0052]FIG. 4a is an example of a policy wizard dialog box according tothe invention;

[0053]FIG. 4b is an example of a policy wizard dialog box according tothe invention;

[0054]FIG. 5 is an example of a policy monitor dialog box according tothe invention;

[0055]FIG. 6 is an example of a query tool dialog box according to theinvention;

[0056]FIG. 7 is an example of a query tool dialog box according to theinvention;

[0057]FIG. 8 is an example of a query tool dialog box according to theinvention;

[0058]FIG. 9 is an example of a query tool dialog box according to theinvention;

[0059]FIG. 10a is an example of a policy wizard dialog box according tothe invention;

[0060]FIG. 10b is an example of a policy wizard dialog box according tothe invention;

[0061]FIG. 10c is an example of a policy wizard dialog box according tothe invention;

[0062]FIG. 11 shows a high-level view of an example network according tothe

[0063]FIG. 12 shows an algorithm according to the invention;

[0064]FIG. 13 shows a flow diagram according to the invention;

[0065]FIG. 14 shows an algorithm according to the invention;

[0066]FIG. 15 shows a high level schematic diagram according to theinvention;

[0067]FIG. 16 shows a schematic diagram of process flow according to theinvention;

[0068]FIG. 17 is a block schematic diagram according to the invention;

[0069]FIG. 18 is a high level flow diagram of the preferred outputsection according to the invention;

[0070]FIG. 19 shows a schematic diagram according to the invention;

[0071]FIG. 20 is an example of a dashboard according to the invention;

[0072]FIG. 21 shows an example of a tear off console according to theinvention;

[0073]FIG. 22 shows an example of an events summary view according tothe invention;

[0074]FIG. 23 shows an example of a conformance event details pageaccording to the invention;

[0075]FIG. 24 shows an example of a protocol event details pageaccording to the invention;

[0076]FIG. 25 shows an example of an events summary page containing apop up description according to the invention;

[0077]FIG. 26 shows an example of an events summary page containing apop up description according to the invention;

[0078]FIG. 27 shows an example of a conformance event details pagecontaining a pop up description according to the invention;

[0079]FIG. 28 shows an example of an alert details page according to theinvention;

[0080]FIG. 29 shows an example of a violators chart and table pageaccording to the invention;

[0081]FIG. 30 shows an example of a targets chart and table pageaccording to the invention;

[0082]FIG. 31 shows an example of an advanced search dialog boxaccording to the invention; and

[0083]FIG. 32 shows an example of a link to the advanced search dialogbox according to the invention.

DETAILED DESCRIPTION OF THE INVENTION

[0084] The invention is a security policy monitoring system and itssupportive features, algorithms, and tools. It is ideally suited fornetwork and security assessments where real network traffic is analyzedin order to identify abnormal traffic patterns, system vulnerabilities,and incorrect configuration of computer systems on the network. Thesystem listens on a network, logs events, and takes action, all inaccordance with a rule based system-wide policy. The system is able toincorporate external sources of event information, such as are generatedin log files of other network components. The system gets protocolinformation, which can make it more meaningful to a networkadministrator. The system sends data upstream to an event log andinterprets the data. The system listens to secure protocols and candecrypt a session if a key escrow facility is available. The systemextracts basic security parameters, such as, for example, networkevents, and passes them to a policy manager component.

[0085] An important part of understanding the invention is understandingnetwork security terminology for policy monitoring. See Table A below.TABLE A Terminology Network Event: One complete transaction on thenetwork, such as a FTP connection or a HTTPS transaction. Each networkevent has several component protocol events. Protocol Event: Atransaction at one protocol level. For example, a network event thatrepresents an FTP connection has protocol events representing an IPassociation, a TCP connection, an FTP control connection, and severalFTP control commands. Initiator, Target: The endpoints of a networkevent or protocol event. Credential: An identification of the initiatoror target of a protocol event at a particular protocol level. Forlower-level protocols, credentials are, for example, IP addresses or UDPport numbers. For higher level protocols, credentials are, for example,user names, file names, or public key certificates. Association: Aplaceholder for a transaction run over a datagram-based protocol such asIP, ICMP or UDP. The invention herein constructs an association tocollect a conversation between two hosts, or processes in the case ofUDP. It is noted that when the invention misses any data packets betweenthe two communicating computers, it might not be able to determine theinitiator and the target of the association. Associative array: A listof value pairs where each associative array entry is indexed by thefirst element of its value pair, which is called the key. Keys arestored in a hash table to make lookups efficient irrespective of thesize of the associative array. Rule: A policy rule governs a specificinteraction, or set of interactions, between two communicating entities.The invention evaluates policy rules against protocol events todetermine if the latter conform to the active security policy.Disposition: The policy definition of what action or state change needsto take place in response to a network event. Policy Domain: A top levelsegmentation of a network, roughly akin to a cloud-like object in anetwork diagram, which hides internal detail. Within the policy domaincommunities of hosts provide or access services. One community of hostsdefines the limits of the domain. Monitoring Point: A point within apolicy domain where it will be possible to plug a machine into thenetwork in order to collect packet data. Communities of Hosts: Amechanism for grouping hosts that have a similar function, e.g. all webservers or all NT workstations. Perimeter Element: A hardware devicethat allows access to and from communities of hosts outside a policydomain. Examples of perimeter elements are firewalls and routers. PolicyLanguage: A policy language is used to create a formal specification ofa network security policy. The preferred embodiment of the inventionincorporates the policy definition language of U.S. patent applicationnumber 09/479,781, filed 01/07/00, entitled, “A Declarative Language forSpecifying A Security Policy.” It defines first class objects such asrules, credentials and dispositions. It is based on s-expressions, whichare LISP-like parenthesized expressions. Rogue server: A machineintroduced to a network that is not authorized to be on that network.Rogue router: An unauthorized router that is added to a network,providing an alternate path into the network. Typically occurs throughmiscon- figuration of switches or dialup connections. Real-timemonitoring: Reading packet data off a network and processing it toevents in a stream, so that an event appearing in the network causes acorresponding event in the stream a short time later. DLL: Any kind of adynamically linked library

System Overview

[0086] The preferred embodiment of the invention translates traffic onthe network into protocol events that are themselves combined intonetwork events. As protocol events are detected, they are comparedagainst a policy. The policy specifies a disposition of the networkevent, as defined by the observed series of protocol events. Informationabout the protocol events, the network event and its disposition isstored in a database. This database of network traffic information canbe mined for policy violations.

[0087] This preferred embodiment of the invention is described withreference to FIG. 1a. FIG. 1a is a schematic diagram of components ofthe system according to the invention. The system comprises a policymonitoring component 100 that takes as input a policy file 105 that hasbeen generated using a policy generator wizard 110 or other means, and afile containing network packet dump data 115 that has been collectedfrom an observed network 125 by a packet capture 126, or that has beenprocessed by a protocol monitor processor 127. The system can alsoprocess packet event data from the observed network 125 in a continuousreal-time mode, without first storing packet data to a file.

[0088] The policy monitoring component 100 comprises a policy managercomponent 106 that itself comprises a parser 101 for parsing the policyfile 105, a policy engine for 102 for assigning policy dispositions tonetwork events, and a logger 103 for determining how to log theinformation processed by the policy engine 102, according to an inputlogging policy 130. It also comprises a database 104 for storingsynthesized information of the packet dump's 115 conformance to thespecified policy 105 performed by the policy engine 102, where it can bemined with a query tool 135. It also comprises a report script component160 for querying the database 104 and creating reports 161, and an alarmscript component 155, for generating alarms based on the severity of thedisposition assigned to network events.

[0089] An equally preferred embodiment of the invention also comprises aparser tool 150 that takes the policy specification file 105 as inputand automatically generates an English description of the policy 151 forthe end user. The parser tool 150 is optional.

[0090] An equally preferred embodiment of the invention also provides asecure Web server feature 162 for the end user to review reports fromthe end user's host computer 163. The secure Web server feature 162comprises the Web server 164 and a report database 165 that hosts thereports 161 generated using the report script 160. The Web serverfeature 162 is optional.

[0091] An equally preferred embodiment of the invention provides securemanagement connections (141, 142) and a secure management host 140 formanaging the policy monitoring component 100 and the combination of thenetwork monitoring components 128, respectively.

[0092]FIG. 1b shows a simpler embodiment of the invention, wherein theparser tool 150 and the secure Web server feature 162 are omitted.

[0093] The default action of the policy engine 102 is that it denies alltraffic. The policy 105 opens holes in this denial to allow permittedtraffic to flow. Although the policy engine 102 assigns a singledisposition to an entire network event, the protocol events aresignificant. As network data 115 arrives, the policy engine 102interprets protocols and generates updates of protocol eventinformation. The policy 105 is consulted as each new piece ofinformation arrives, so that the earliest determination of dispositionis reached. For example, if the policy 105 states that a given IPaddress may not communicate with another IP address, the policy 105 cangenerate a disposition immediately upon receiving the first packet 115of the network event.

[0094] To aid policies in early determination of disposition, the policylanguage divides dispositions into immediate and final. An immediatedisposition fires immediately, i.e. its value becomes associated withthe network event right away. A final disposition sets a bookmark toitself as the latest and best disposition. When all protocol events areprocessed without an immediate disposition, the last bookmark set is thedisposition that is applied to that network event. Immediatedispositions are designed to generate early results and to allow policywriters to issue a definitive disposition for the network event based onthe information received up to that point. Final dispositions allow forthe possibility that a better disposition might be determined later on.In other words, they allow the policy engine 102 to make a more informeddecision based on additional protocol events that might be received asthe network event progresses.

[0095] Overview of the Components

[0096] An overview of main components of the preferred embodiment of theinvention is discussed below with reference to FIG. 1.

[0097] Policy Generator

[0098] The preferred embodiment of the policy generator component 110,also referred to as policy wizard, is a program that makes an end userreadily able to generate a first-pass policy for a new site. Policyinformation is input into a set of dialog boxes and a policy isgenerated. The wizard enables the end user to generate policy based onwhat can be considered gross characteristics of a network at the IPlevel, such as, for example, policy domains, communities of hosts,servers, subnets and firewalls, as well as at the UDP/TCP service level.For example, such network characteristics can comprise communities ofhosts that can access certain services on server hosts.

[0099] Once a policy has been generated with the wizard, it is output inthe policy specification language 105 so that it may be directlyprocessed by the policy monitor component 100. The policy wizard 110 isalso able to save files at the wizard level, i.e. such that the policymay be refined in the wizard and regenerated.

[0100] Policy Monitor

[0101] The policy monitoring component 100 comprises a suitable userinterface, such as an MFC-based front end or a command line interface,and the policy manager 106. The policy manager 106 performs the actualexamination of a sequence of event updates stored in a file ortransmitted in a continuous stream 115 in the context of a policyspecification 105 and signals the adherence to the policy via recordswritten to the database 104.

[0102] Network Monitor

[0103] The network monitor component 127 provides the followingcapabilities:

[0104] Streams-based interpretation of packet dump data 126 in, forexample, DMP format; and

[0105] Packet- and connection-based textual logging of protocolinformation. Logging is selectable by protocol and may be enabled onlyfor one or more connections. In another embodiment of the invention, thenetwork monitor 127 can perform serialization of event data. That is,the network monitor 106 can process a packet capture file 126 into aseries of event updates that contain only the salient security detailsfor processing by the policy monitor 100. The resulting file issignificantly smaller than the original, for example, approximately{fraction (1/20)}^(th) to {fraction (1/100)}^(th) the size of theoriginal. It is also possible for sensitive data, such as passwords anddocuments, to be removed from the file. However, it should beappreciated that the original packet capture file is needed to performfull analysis.

[0106] In another embodiment of the invention, the network monitor 127can read packet data directly from observed network 125, generating acontinuous stream of event updates for the policy monitor 100. Thisstream operates in real-time so that the policy monitor 100 processesevents shortly after they happen on observed network 125.

[0107] It should be noted that the network monitor 127 can be used as astandalone tool, but typically is invoked from within the policy monitorcomponent 100 and the query tool 135 in normal operation of theinvention.

[0108] It should also be noted that the network monitor and the policymonitor may run on the same machine.

[0109] For a more detailed discussion on the internals of the networkmonitor, refer to the section, below entitled “Network Monitor InternalsDescriptions.”

[0110] Query Tool

[0111] The query tool 135 allows the end user to view the data that hasbeen stored in the database 104 by the policy manager 106.

[0112] Policy Compiler

[0113] The policy compiler performs syntactic and semantic checking of apolicy specification. Upon successful compilation the compiler ascontrolled by runtime arguments, may:

[0114] Generate a DLL containing a compilation of credential andcondition verification code; and

[0115] Generate a pseudo-english report that summarizes the policy.

[0116] It should be appreciated that it is not necessary to run thecompiler because the policy monitor component automatically compiles andinstalls policy from the policy specification file.

[0117] Platform

[0118] The policy generator 110 runs on a Windows NT or Unix machine,while the policy monitor 100 and the network monitor 127 run on Linuxmachine(s). It should be appreciated that these components can runequally well on other suitable operating systems. In addition to policyand network monitoring software, the following software components arealso installed on the appropriate machines:

[0119] Microsoft Visual C++6.0;

[0120] Sybase ASE 11.9.2; and

[0121] NT NDIS packet drivers and Windump 2.0.

[0122] It should be appreciated that these components can run equallywell on other compilers, databases, and packet monitoring systems.

[0123] Policy Files

[0124] There are two file types that are used within the invention'senvironment, and are described below in Table B. TABLE B File TypeSuffix Description Policy wizard File .spw Intermediate file used by thepolicy wizard to store policy information between invocations. Policymonitor File .spm Output file generated by the policy wizard and used asthe policy input into the policy monitor. Contains a description of thepolicy in the policy language.

[0125] The preferred embodiment of the invention incorporates a highlevel workflow method for developing policy, as follows:

[0126] 1) Creating an initial policy using the policy generator tool;

[0127] 2) Uploading the policy file to a remote machine;

[0128] 3) During the initial policy development phase, running thenetwork monitor to collect traffic, and the policy monitor to analyzetraffic separately, as follows:

[0129] a) Running the network monitor and specifying an output file ofthe collected traffic, and possibly specifying via parameter a limit tothe number of packets captured, e.g. 50,000;

[0130] b) Running the policy monitor to analyze traffic collected byspecifying the file containing the collected traffic;

[0131] 4) Examining the output of the policy monitor run by querying thedatabase using the query tool;

[0132] 5) Modifying the policy as needed using the policy generatortool; and

[0133] 6) Repeating steps 2 through 5 until a comprehensive desiredpolicy is defined. At this point the end user may start monitoringnetwork traffic on a continuous basis, and using generated reports asinput for further policy refinement.

[0134] High Level Workflow Example

[0135] The high level workflow described above can be illustratedfurther by understanding an example, as follows. System components ofthe invention are referenced using FIG. 1. Screen interactions aredescribed with reference to the preferred embodiment of the invention.Other screen displays with similar function might equally well embodythe invention.

[0136] Referring to FIG. 2, an initial policy is generated (201). Oftenthe initial policy is created from corporate network policy, in whateverform that may take, and a network topology diagram. For the sake of thisexample, it is assumed that the policy wizard 110 was used to generatean initial, simple policy 105.

[0137] Next, compliance of current network traffic to this initialpolicy is monitored (202). Such monitoring is achieved by collectingpacket information off the network and running such data 115 against theinitial policy 105 using the policy monitor 100.

[0138] Then the query tool 135 is used to data-mine output network eventdata from the database 104, using the mined data to check for trafficthat is not consistent with the policy 105, and reporting the results(203).

[0139] Once anomalies have been found, the next step is to work outwhere the problem lies. The problem could be network equipment ismisconfigured and needs to be corrected (203); otherwise acceptablebehavior is not covered currently by the policy specification file thefile needs to be corrected (204); or, otherwise acceptable behavior isnot covered currently by the corporate policy and the corporate policyneeds to be corrected (205). In the case of this example, it is assumedthat the policy specification 105 is incomplete and an end user needs toadd a new rule to permit the observed traffic pattern.

[0140] Generate a Policy Specification File From a Wizard Policy

[0141] The end user starts the policy generator tool, or wizard 110, bydouble clicking on a policy wizard shortcut on the end user's desktop.In the preferred embodiment, a window such as depicted in FIG. 3 opens.

[0142] In this example, the end user has opened a file,c:\spm\quickstart\null.spw, through the File->Open menu item 301. Thisfile contains a very simple policy that defines a single policy domaindefined by a 10.0.0.0/8 subnet mask. Rules within this policy denyessentially all traffic.

[0143] The end user chooses to compile the policy, whereby the dialogbox in FIG. 4 opens. The end user presses the “Process Policy” button401 and a file named null.spm in the output file exntry field 402 isgenerated and saved.

[0144]FIG. 4b shows the dialog box in FIG. 4a with printed results fromthe compile process in a text window 403.

[0145] File Running Policy Monitor Over Canned Data

[0146] The end user starts the policy monitor 100 by double clicking ona policy monitor shortcut on the desktop. In the preferred embodiment, awindow such as depicted in FIG. 5 opens.

[0147] The end user ensures that the “Input Dump File” entry field 501points to a data dump file, here qs.dmp, and that the “Policy” entryfield 502 points to the null.spm (monitor) file that the end usergenerated above. The “Monitoring Point” entry field 503 is derived froma policy domain name “Intranet” that is present in the null.spw (wizard)file.

[0148] The end user ensures database connectivity information is setcorrectly. The ODBC entry field 504 with entry “sybase” points to aSybase database running on a local machine. The username “policy” 505with some password, shown as “******” 506 have been preinstalled.

[0149] The end user presses the Run button 507 and the .dmp file isprocessed through the policy specification file 105 placing the outputdata into the database 104.

[0150] Look at the Results Using Query Tool

[0151] The end user starts the query tool 135 by double clicking on aquery tool shortcut on the desktop. In the preferred embodiment, awindow such as depicted in FIG. 6 opens.

[0152] The end user presses a “Network Events” button 601 and the dialogbox depicted in FIG. 7 appears. FIG. 7 is a dialog box that allows theend user to enter login information for the database 104.

[0153] Here, the end user enters the same username and password as wasused in policy monitor 100 and connects to a database 104 named Policyon localhost.

[0154] When connected, the screen shown in FIG. 8 appears. FIG. 8 is adialog box that allows the user to select which processed network datato view from database 104. The topmost entry in the “Execution Run”pull-down contains most recent data was added to the database 104. Inthis case it is current processing of the qs.dmp file. The end userpresses the “Query” button and network event information for this run isretrieved from the database 104 and shown in as in FIG. 9.

[0155]FIG. 9 shows a queried rule view dialog box according to thepreferred embodiment of the invention. FIG. 9 shows that the null.spwpolicy has denied all traffic. The network events having dispositionUdp_Access_Denied represent DNS lookups from an internal host(10.5.63.143) to another internal host (10.5.63.6). It is assumed forthis example that this is traffic conforming to policy, and thereforethe end user adds a rule to the policy to permit this event.

[0156] Add a New Rule Using the Wizard

[0157] The end user returns to the policy wizard main window and pressesthe “Edit Rules” button which opens a dialog box as shown in FIG. 10a.FIG. 10a shows a dialog box for generating a new rule according to theinvention. The end user selects the “Intranet” domain from the “PolicyDomain” pull-down to add a rule for our Intranet domain. The end usertypes a rule name, such as Internal_Dns into the “Rule Name” field andpresses the “New” button. The end user selects the communities andservices to which this rule applies. For simplicity in this example, theend user wants to allow DNS from any internal nodes to any otherinternal nodes and therefore selects an Initiator community of hostsInside_Nodes, a service of DNS, and a Target community of hostsInside_Nodes. The end user then presses the “Add Selected” button foreach in turn to create a rule as shown in FIG. 10b, where FIG. 10b showsa dialog box for generating a new rule according to the preferredembodiment of the invention.

[0158] Next the end user generates a new policy specification file andruns policy monitor. The end user returns to the query tool and pressesthe “Network Events” button again to get a new rule view dialog box. Thetopmost “Execution Run” is now the output from the processing justcompleted. The end user presses the “Query” button and can now see thatDNS traffic from 10.5.63.143 to 10.5.63.6 is now conformant to thepolicy as shown in FIG. 10c, where FIG. 10c shows the communities of thepolicy specification.

DETAILED DESCRIPTION OF COMPONENTS

[0159] The preferred embodiment of the invention incorporates thefollowing components, detailed description of which follows below.

The Policy Generator Tool

[0160] The preferred embodiment of the invention provides a policygenerator tool, or simply policy generator, equally referred to aspolicy wizard, that provides a level of abstraction on top of the policylanguage, and which simplifies the process of creating an initial policybased on gross characteristics of a network at the IP level, such aspolicy domains, communities of hosts, servers, subnets, firewalls.

[0161] The policy generator provides a novel mechanism for translatingdesired network security policy, such as corporate network securitypolicy, into a policy specification file that can be interpreted andimplemented by a policy monitor mechanism.

[0162] Building a policy with the policy wizard involves: deciding onlogical divisions within the network, i.e. policy domains, groupingnetwork nodes into logical communities, and expressing rules about whichcommunities of hosts can provide what services to which communities ofhosts.

[0163] High Level View of Policy Generation

[0164] The first step in building a basic policy is to define ahigh-level topology for the network. Not much detail is necessary. Inthe preferred embodiment of the invention, the network needs to bedivided into bounded units called policy domains. In practice, thechoice of a policy domain boundary is fairly obvious. Usually naturallogical and physical boundaries in a network help define policy domainboundaries. For example, firewalls and routers with packet filterscommonly denote the important boundaries. When defining a simple policy,it is reasonable to ignore switches, bridges, hubs, and routers thatconnect interior subnets.

[0165] It is suggested that policy domains be as small as required bytraffic monitoring limitations and as large as specification of rulesallow. Rules are written about traffic visible in a policy domain.Traffic in a policy domain is logically considered to be visibleanywhere within the policy domain even though networking elements, suchas, for example, switches prevent such visibility in most networks. Bywriting rules about traffic as though it is visible anywhere within thepolicy domain, the same set of rules can be applied to network trafficanywhere within the policy domain.

[0166] It has been found that if a policy domain is too small, rulesneed to be duplicated for each extraneous policy domain. If a policydomain is too large, then the choice of a network traffic monitoringpoint can become overly constrained, or the ability to detect IPspoofing and rogue routers is lost.

[0167] Identify the Policy Domains

[0168]FIG. 11 shows a high-level view of an example network. An Intranet1101 is connected to a DMZ 1102 through a firewall 1103. The DMZ 1102,in turn, connects through a router 1104 to the Internet 1105 and througha second router 1106 to an external corporate network 1107. In thisexample, an end user is only expected to be able to monitor traffic inthe Intranet and DMZ, so these two entities are declared to be policydomains. Rules in the policy only apply to allowed traffic in the DMZand Intranet. The corporate network and Internet are viewed only ascommunities of hosts visible from within the policy domains.

[0169] It should be appreciated that the end user could choose todeclare the Internet and Corporate network to be policy domains, but, bydoing so, would only create unnecessary work because the end user doesnot intend to monitor traffic there. Any rules generated would thusnever be used.

[0170] Add Perimeter Elements

[0171] In the preferred embodiment of the invention, the point ofconnection of a policy domain to the outside world is known as aperimeter element. For each perimeter element the set of nodes visiblethrough it needs to be known and, for generating rules to detect IPspoofing and rogue routers, the MAC address of the perimeter elementitself needs to be known.

[0172] As an example, if an end user could sit inside a policy domainand look out through boundaries, it is probable that the end user wouldsee a filtered version of what is on the other side. Network addresstranslation (NAT) can change the IP addresses seen though the boundary.For example, a proxying firewall may not let the end user see anythingdirectly beyond a single IP address at the boundary. Filters may limitthe view to only a few hosts when thousands are actually present.

[0173] Define Communities

[0174] In the preferred embodiment of the invention, communities consistof sets of IP addresses. They can be expressed as, for example,individual IP addresses, ranges of addresses, or subnet masks.Additionally, communities can be composed of other communities. It isoften the case that a community of nodes involves all nodes in someexisting set except for a node or two. Communities are defined in termsof included elements and excluded elements.

[0175] Define Rules for Each Policy Domain

[0176] In the preferred embodiment of the invention, rules defined for apolicy domain describe allowed transactions. For example, if no rulesare written, the policy specifies that everything at the IP level orabove is denied, although this specification is not strictly truebecause typically auto-generated rules that apply to IP broadcasttraffic and ICMP traffic within the policy domain exist. Rules createholes in this base layer that declares all traffic illegal.

[0177] Rules are defined in terms of initiator communities, targetcommunities, and the services allowed. Services consist of a set of portnumbers and indicators of whether TCP or UDP protocols are used.

[0178] Using the Policy Generator

[0179] The preferred embodiment of the invention provides a front endfor the policy generator. It provides a user interface for entering andediting a simple policy. The front end reads and writes the currentstate of a policy from or to an intermediate file. The currentlypreferred extension for the intermediate file is .spw. When a policy hasbeen specified to the satisfaction of the end user, it is written to anintermediate policy file for processing by the policy generator backendthat generates a formal policy specification file compatible with thepolicy monitoring system.

[0180] The front end allows the end user to edit policy domains,communities, services, and rules, to read and write the current policyfrom or to an intermediate file, and to process the intermediate policyfile into the formal policy specification file.

[0181] The preferred embodiment of the invention allows severalinstances of each editing process to be open simultaneously. Theinteraction is intended to feel very live. Data changed in one editingprocess should be reflected in the contents shown in other editingprocesses. For example, if a community is added in one community editingprocess, then it is immediately available for use in all editingprocesses. When building a policy, entities are first created, thenfilled in. From the time of creation they can be used throughout thepolicy. Consequently, a community or policy domain does not need to befully specified in order to be used. However, to prevent errors inbackend processing, all entities should be complete before theintermediate policy file is submitted to the backend for policyspecification file generation.

[0182] In the preferred embodiment, only one policy is under developmentat any time. The front end starts up containing a default policy that isempty except for some predefined default services. This policy can beused as a starting point or an existing policy can be read from a savedintermediate policy file.

[0183] It has been found that it is best to use simple names indeveloping a policy and to use a name that makes sense from apredetermined point of reference, not a fully qualified name that makessense from any point of reference. For example, it is better to give arule a short, descriptive name such as, “Allow_Outgoing_Mail” than togive the rule a long name such as,“Allow_Mail_From_Intranet_To_Outside_Intranet”.

[0184] For an in-depth understanding of the formal policy specificationgenerated by the policy generator, or policy wizard, please refer to thesection, Understanding the Wizard Generated Policy, below.

Collecting Packet Data

[0185] The preferred embodiment of the packet gathering component 128 isa program referred to as the harvester. It reads packets off theobserved network 125 and writes them to either a packet capture file 126or to a TCP socket that is connected to the policy monitor 100.

[0186] As an example, the harvester reads packets off the network wheninvoked as follows:

[0187] harvester-i eth0-c 1000-dump qs.dmp

[0188] In this example, 1000 packets are read from a network interfacelabeled ‘eth0’ and stored in file ‘qs.dmp.’

[0189] The harvester can also be configured to read packet data andconvert it to event data suitable for policy monitor 100. As an example,the harvester may be invoked as follows:

[0190] harvester-i eth0-c 1000-enc qs.dme

[0191] In this example, 1000 packets are read off the network interfacelabeled ‘eth0’, converted to event data suitable for policy monitor 100,and stored in the file ‘qs.dme’.

[0192] The harvester can also be configured to read packet data, convertit to event data suitable for policy monitor 100, and stream such datadirectly to the policy monitor in real time. As an example, theharvester may be invoked as follows:

[0193] harvester-i eth0-c 1000-enc 10.5.63.6:333

[0194] In this example, 1000 packets are read off the network interfacelabeled ‘eth0’, converted to event data suitable for policy monitor 100,and transmitted in a TCP network stream to port 333 on the machine withIP address 10.5.63.6. This machine and TCP port may be configured sothat the policy monitor 100 reads the data and processes it.

[0195] It should be appreciated that the events are transmitted as theyare processed, so that the policy monitor 100 is able to see eventsshortly after they occur on the observed network 125.

[0196] In this mode of operation, the policy monitor 100 is also able topass information about policy dispositions back to the harvester. Theharvester can use this information to make processing of packets moreefficient. For example, if the policy monitor 100 has determined that agiven network event is acceptable according to the policy, the monitorcan sometimes expedite its protocol processing by skipping packets untilthe network event terminates.

Policy Monitor

[0197] The preferred embodiment of the invention provides a policymonitor component that provides a user interface, either graphical orcommand line, that allows the configuration of various options of themonitor, policy engine and logger.

[0198] Monitor Configuration

[0199] Monitor configuration allows the end user to configure thelocation of the input packet dump, policy to be used, and thespecification of the monitoring point.

[0200] The Input dump file specifies the input file, in tcpdump formatthat is to be used.

[0201] The Policy input specifies the .spm file that contains the policyspecification to be used.

[0202] The Monitoring Point is a specification of where the Input dumpfile was collected. This name is derived from policy domain names thatare specified in the policy wizard. For example, if a packet dump wascollected in a policy domain named “Intranet” then the Monitoring Pointname INTRANET_MONITOR should be used.

[0203] Monitor Logging Options

[0204] The monitor logging options allow the end user control of thelocation and the amount of data that gets written to the backenddatabase.

[0205] The Execution Run Comment field allows the entry of freeform textthat is added to the logs in the database to help identify thisparticular run of policy monitor.

[0206] ODBC Name provides the name of the ODBC source to which outputdata is written. The DB Username and DB password are the end user'sdatabase login information. The Save Password allows the program to savethe password in the clear so that it does not need to be entered thenext time the program is run.

[0207] Output Options

[0208] Output options allow the end user to specify whether the traceoutput from the monitor should be displayed in a console window (Outputto console) or sent to a file (Output to file:).

[0209] Advanced Options

[0210] Advanced options allow more options to be set. In day to dayoperation, it is rare that such options need to be changed.

[0211] Advanced Monitor Configuration

[0212] An Assert DLL parameter allows specification of the name of theDLL to be used to verify condition and credential assertions. Note thatif this DLL does not match the version of the policy specified then thisDLL is regenerated, overwriting the provided DLL.

[0213] A Trace Options parameter allows the end user to provideconfiguration of runtime trace options. This option affects the amountof output generated by the monitor. For a more efficient operation, thisfield should be left blank.

[0214] A Certificate Dir argument points to a directory that containstrusted CA root certificates in DER encoded form.

[0215] Advanced Packet Logging Options

[0216] The packet logging options section allows the configuration ofthe trace options to be provided by the low level packet monitor. Thevarious logging options may be specified at a global level (by settingthem for layer “-All-”) or individually on a per-layer basis. Again itis to be noted that specifying logging options adversely affect theperformance of the monitor.

[0217] The Site Handle parameter specifies a name that is associatedwith the particular company or site that is being monitored. It is usedto segment a table that is used for IP-address name resolution withinthe output database.

[0218] Advanced Monitor Logging Options

[0219] The Disable Logging checkbox disables the writing of all loggingdata to the database. If logging is enabled then the remainingcheckboxes provide for the enabling or disabling of the logging ofnetwork events with the given final disposition code. For example, ifDisable Logging is not selected and only

[0220] Policy Error selected then the only network events that arelogged to the database are those that resulted in a final dispositioncode of POLICY_ERROR.

[0221] During normal operation information about all protocol eventswithin a network event is logged, even those that occurred after a finaldisposition was reached. An Enable All Layer Logging parameter cancontrol this feature. When set on, all protocol events are logged to thedatabase. When not set only those protocol events that are processedbefore a disposition is reached are logged.

Query Tool

[0222] The preferred embodiment of the invention provides a query toolto examine the data that was placed in the database. The preferred querytool allows the following functions to be performed:

[0223] Examining network events, such as protocol events, that arecontained within the execution runs in the database;

[0224] Examining IP Connectivity for execution runs in the database;

[0225] Editing and making user defined SQL queries to the database;

[0226] Performing forward and reverse DNS lookups (using the current DNSconfiguration);

[0227] Viewing policy monitoring run information from the database, andselecting a default run for further viewing;

[0228] Explicitly connecting to a specific database; and

[0229] Turning on/off IP address to hostname resolution.

Other Tools

[0230] The preferred embodiment of the invention provides other toolsdiscussed below.

[0231] Compiler

[0232] In its simplest form the compiler needs just a single argumentthat is the input policy specification file. This form is often all thatis needed while doing initial development of a policy. It should beappreciated that the compiler is rarely used in standalone form sinceits function, with the exception of the -r flag, is subsumed into thepolicy monitor component.

Example Usage

[0233] During initial development a command such as the following couldbe used while getting rid of syntactic and semantic errors from thepolicy under development:

[0234] pmsCompiler.exe security.pms

[0235] Once compiler errors are gone, the end user is ready to generatepieces that are used to run the policy monitor. For example, the enduser can use the command line:

[0236] pmsCompiler.exe -d verify security.pms

[0237] that compiles the security policy, and generates a verificationDLL named “verify.dll”.

[0238] Compiler Options

[0239] The following arguments in Table C may be provided to the examplepmsCompiler.exe. TABLE C pmsCompiler -? -r -c <cxx-file>-d <dll-file><policy-file>*

[0240] -c<cxx-file>

[0241] Generate Credential and Condition assertion verification code tothe named file. The suffix “.cxx” is appended to the name that isprovided. This option is rarely used to allow the end user to look atthe actual code that is used to verify assertions.

[0242] -d<dll-file>

[0243] Generate a DLL containing the assertion verification code to thenamed file. The suffix “.dll” is appended to the name that is provided.If the -d flag is used without the -c flag then the source code iswritten to a temporary file. This option is often used to generate theassertion verification DLL. The alternative is to allow the runtimePolicy Monitor to generate the DLL for itself.

[0244] -r

[0245] Generate a pseudo-english description of the policy to stdout.The output of this command is a useful starting point for a policyreport to a customer.

[0246] ?

[0247] Display a usage string.

[0248] <policy-file>

[0249] The required policy specification (“.pms”) file.

[0250] -b<db-name>

[0251] Store information about the compiled policy in the nameddatabase. db-name is the name of a user data source that has beenconfigured within Control Panels->ODBC. This argument is rarely used.The alternative is to allow the runtime Policy Monitor to write thepolicy to the database if needed.

[0252] -o<output-file>

[0253] Redirect compiler messages to stdout to the named output file.Rarely used.

[0254] -t<trace-opts>

[0255] Enable debug tracing. For more specific details try providing theargument “-t?”. This option is rarely used because it only providesinformation to allow debugging of the compiler itself.

[0256] -v

[0257] Use VisualC++ to preprocess macros rather than the internalpreprocessor. This overrides the -n option. This option is rarely used.

[0258] Add debug trace code, i.e. printf statements, to the generatedCredential and Condition verification code. The generated code iscompiled with symbol information (the C compiler -g flag). This optionis rarely used.

[0259] -n

[0260] Do not run a preprocessor. C preprocessor macros such as #defineand #include may be included within a policy file. This option specifiesthat the pre-compiler should not be run prior to actually compiling.This option is rarely used.

[0261] -z

[0262] Output the dump output of the parsed policy. This output looksremarkably similar to the input file with the comments stripped and somecomponent definitions reordered.

[0263] Network Monitor

[0264] The preferred embodiment provides a streams-based network monitorthat can be run in a standalone mode independent of the policy monitor.In this way it can be used to provide a detailed, streams-based view ofthe network traffic, or a subset thereof. For example, run in standalonemode is desirable when a particular protocol is not supported nativelyby the policy monitor and an end user desires to see raw data to gain anunderstanding of what is going on.

[0265] It should be appreciated that a convenient way of accessing suchfunctionality is through the query tool.

Example Usage

[0266] The following invocation of the network monitor:

[0267] mon -ev 2 -I ALL=all C:\spm\quickstart\qs.dmp examines the qs.dmpfile, producing extremely verbose output for event 2 only.

[0268] Table D provides a list of network monitor options according tothe invention. TABLE D Monitor Options  mon [-logLAYER[=[-]option1,[-]option2...]]*  [-n npkt] [-skip pkt] [-untilendpkt]  [-ev eventiD] [-untilev eventid] [-justev eventid] [-noclients] dump_file  -log  -n npkt  Only process the first npktpackets from the input data.  -skip pkt  Skip pkt packets beforebeginning to process the input data.  -until endpkt  Only process datathrough the packet number provided is reached  -ev eventID  Only processthe data starting at the given eventID.  -untilev eventid  Only processthe data through eventid. Note that to find the end of  eventid, eventswith ids greater than eventid may be processed.  -justev eventid  Onlyprocess the data for eventid. Note that to find the end of  eventid,events with ids greater than eventid may be processed. This  option isthe equivalent of -ev eventId -untilev eventId.  -noclients  Do notgenerate any output for higher level protocols such as  HTTP, FTP, etc. dump_file  The dump file, in tcpdump/windump format, that contains theinput data.

[0269] Understanding the Wizard Generated Policy

[0270] Using the Policy Generation Wizard, a user specifies a networksecurity policy in terms of the network services provided by certainhosts to other hosts in the network. When such policy is processed, thewizard generates a formal and more detailed description of the networksecurity policy using the policy language. The policy languagespecification may then be used to analyze network traffic using thepolicy monitor tool. The results of this analysis can be studied usingthe query tool. An exemplary policy language is taught in A DeclarativeLanguage for Specifying a Security Policy, patent application Ser. No.09/479,781 (Jan. 7, 2000).

[0271] Understanding the output of the preferred query tool requiresunderstanding how the preferred wizard translates the high-level view ofsecurity policy it presents to its users into a set of policy languageobjects such as rules, credentials and dispositions.

[0272] Understanding the policy generation process involves thefollowing:

[0273] Understanding the predefined rules, credentials and dispositions;

[0274] Understanding the implicit rules and credentials; and

[0275] Understanding the explicit rules and credentials.

[0276] Predefined Rules, Credentials and Dispositions

[0277] Every policy generated by the wizard includes a set of predefineddefault rules for handling protocol events that do not conform to theuser-defined policy i.e. rules that deny access, as well as rules forhandling common network events not covered by the user policy. Theserules and their dispositions are shown in Table E and Table F, andfurther discussed below. TABLE E Rule Protocol - Action DispositionIp_Deny IP - all Ip_Access_Denied Icmp_Deny ICMP - allIcmp_Access_Denied Udp_Deny UDP - all Udp_Access_Denied Tcp_Deny TCP -all Tcp_Access_Denied Http_Deny HTTP - all Http_Access_Denied Ftp_DenyFTP - all Ftp_Access_Denied Ssl_Deny SSL - all Ssl_Access_DeniedSsh_Deny SSH - all Ssh_Access_Denied

[0278] Table F shows the default rules for all the protocols supportedby the policy monitor. The policy engine selects these rules when noother rule can be found that is satisfied by the protocol event. TABLE FRule Protocol - Action Disposition Ip_Deny_Pure_IP IP - PROTOCOL_UNKNOWNDeny_Pure_Ip Tcp_Missed_Connections TCP - MISSED_CONNECTWarn_Missed_Tcp_Connect Ftp_Ignore_Data_Connections FTP - DATA_OPEN ok

[0279] Table G below shows rules that cover protocol events notaddressed by the wizard's user interface. These are well understoodevents that can be separated from those handled by the default rules.Ip_Deny_Pure_Ip is assigned to IP associations whose payload is not oneof the three well-known IP-based protocols (ICMP, UDP and TCP).Tcp_Missed_Connections is assigned to network events where theestablishment of the TCP connection was not witnessed by the policymonitor. Ftp_lgnore_Data_Connections is assigned to all FTP dataconnections which, from a security policy monitoring perspective, can besafely ignored. It is noted that the preferred policy wizard generatesother rules to deal with common protocol events as discussed below.

[0280] Table G shows the predefined dispositions used by all the rulesin the generated policy. Associated with each disposition are itsdisposition code and severity, which may be used in the query tool tofilter network events. TABLE G Disposition Disposition Code DispositionSeverity ok OK None policy-error POLICY_ERROR CRITICAL Ip_Access_DeniedACCESS_DENIED HIGH Deny_Pure_Ip ACCESS_DENIED HIGH Monitor_Broadcasts OKMONITOR Icmp_Access_Denied ACCESS_DENIED HIGH Monitor_Icmp OK MONITORUdp_Access_Denied ACCESS_DENIED HIGH Tcp_Access_Denied ACCESS_DENIEDHIGH Warn_Missed_Tcp_Connect OK WARNING Ftp_Access_Denied ACCESS_DENIEDHIGH Http_Access_Denied ACCESS_DENIED HIGH Ssl_Access_DeniedACCESS_DENIED HIGH Ssh_Access_Denied ACCESS_DENIED HIGH

[0281] It should be noted that ok and policy-error are actually built-indispositions in the policy language. If policy-error is encountered itindicates an error in the processing of either the policy or the networktraffic data by the policy monitor. The meaning of the otherdispositions is explained later in this document in the context of therules in which they are used.

[0282] Finally, the wizard includes a set of predefined credentials thatare combined with dynamically generated credentials and used inimplicitly generated rules:

[0283] _Multicast_Addresses—a set of commonly used IP multicastaddresses;

[0284] Local Broadcast Address—the IP address used for non-directedlocal broadcasts (255.255.255.255); and

[0285] _Zero_Ip_Address—a zero-valued IP address (0.0.0.0), commonlyused by BOOTP clients;

[0286] It is noted that the double underscore prefix in these credentialnames is used to ensure that there aren't any name conflicts withcredentials generated to represent user-defined communities andservices.

[0287] Explicit Rules and Credentials

[0288] Every community defined by the user results in a credential ofthe same name. Because the scope of a community name is that of theentire policy specification, the resulting credential names need not bemassaged to ensure uniqueness.

[0289] Service names are also global in scope. Because services andcommunities share the same name space, every service defined in thepolicy results in a credential whose name is constructed by prefixingthe user-supplied service name with the underscore character. Thus, forexample, the Smb service is represented by a credential named_Smb.

[0290] Rule names, on the other hand, are only unique within the scopeof a policy domain. Furthermore, if a user-defined rule addresses aservice that is both a UDP and a TCP service, the wizard generates tworules, one for the UDP protocol and another for the TCP protocol. Thus,a rule name is constructed by prefixing the user-supplied name with theprotocol name (Udp_or Tcp_) and the policy domain name.

[0291] For example, if the user defines a rule titled Smb_Serviceswithin a policy domain named Intranet, the wizard generates two rules,Udp_Intranet_Smb_Services and Tcp_Intranet_Smb_Services, for the UDP andTCP protocols respectively.

[0292] User-defined rules may also result in the generation ofadditional credentials. When defining a rule, the user provides thefollowing information:

[0293] Zero, one, or more initiator communities;

[0294] Zero, one, or more services; and

[0295] Zero, one, or more target communities.

[0296] If more than one initiator community are specified, the wizardgenerates a credential that combines these communities into a union. Thecredential name is constructed by appending the word_Initiator to theuser-supplied rule name, prefixed by the policy domain name. Using theexample above, the wizard would create a credential namedIntranet_Smb_Services_Initiator.

[0297] Likewise, if more than one target communities are specified, thewizard creates a credential representing their union and names it byappending the word_Target to the policy domain and rule names, e.g.Intranet_Smb_Services_Target).

[0298] However, if one or more services are specified they are combinedwith the target credentials according to the service type. For example,the Smb service (for the SMB protocol suite) and its like-namedcredential include ports that are used for both TCP and UDP. Thus, forthe Smb_Services rule used above, the wizard would generate thefollowing additional credentials: Udp_Intranet_Smb_Services_Target andTcp_Intranet_Smb_Services_Target. These credentials combineIntranet_Smb_Services_Target (or a single target community) with the_Smbcredential and constitute the actual target credentials used inUdp_Intranet_Smb_Services and Tcp_Intranet_Smb_Services respectively. Itshould be noted that, in many cases, the set of UDP and TCP servicesreferenced in a rule have little, if any overlap.

[0299] If the end user does not specify any services the wizard uses theIntranet_Smb_Services Target credential (or a single target communitycredential) to identify the target principal.

[0300] Implicit Rules and Credentials

[0301] For each policy domain within the policy specification, thewizard automatically generates a set of rules and credentials thatdefine the valid IP-level traffic seen at the monitoring point withinthe domain. In addition, an ICMP rule is generated that handles allintradomain ICMP traffic, as well as a credential for the monitoringpoint in that domain.

[0302] The monitoring point credential is based on an agent descriptorstring manufactured by the wizard. The agent descriptor is constructedby converting the policy domain name to uppercase and appending to itthe word _MONITOR. Thus, for example, a policy domain named Intranet isassigned the agent descriptor:

[0303] INTRANET_MONITOR.

[0304] Note that this is the agent descriptor to be used in the policymonitor when analyzing data collected at this monitoring point.

[0305] The monitoring point credential itself is named by appending theword _Monitors to the policy domain's name. In the example above, thecredential is named Intranet_Monitors.

[0306] The wizard segregates all intradomain ICMP traffic (common on anenterprise network) by use of a rule that assigns it the dispositionMonitor_Icmp. The rule is named by combining the protocol name with thedomain name using the word_Within. For example, in the Intranet policydomain the rule is named Icmp_Within_Intranet.

[0307] IP traffic is described by a set of rules that systematicallyenumerate all valid IP-level traffic within the policy domain, betweenhosts in the policy domain and external hosts, and between externalhosts through the policy domain (when more than one perimeter element ispresent). Most of these rules provisionally allow IP traffic, lettingthe subsequent protocol layers (ICMP, UDP, TOP, etc.) determine if thetraffic is indeed allowed either by a user-defined (explicit) rule or bya predefined rule.

[0308] The first IP rule provisionally allows all intradomain IPtraffic. It is named by combining the protocol name with the domain nameusing the word_Within (e.g., Ip_Within_Intranet). In the absence of ahigher-level protocol within an intradomain IP association, the ruleassigns the network event a disposition of Deny_Pure_Ip, i.e. its finaloutcome.

[0309] The intradomain IP rule uses the policy domain's definingcommunity as its target principal. However, it generates anothercredential to be used as the initiator. This credential combines thedefining community with the predefined credential for zero-valued IPaddresses (_Zero_Ip_Address). The generated credential is named byappending the word_Initiator to the generated rule name, e.g.Ip_Within_Intranet_Initiator.

[0310] Another intradomain IP rule is used to segregate typicalbroadcast and multicast traffic within an enterprise network. It isnamed by combining the protocol name with the domain name using thewords_Broadcasts_Within, e.g. Ip_Broadcasts_Within_Intranet. Itsinitiator principal is the same as that used for the general intradomaintraffic, e.g. Ip_Within_Intranet_Initiator. Its target is a newcredential constructed by combining the predefined credentials_Multicast_Addresses and_Local_Broadcast_Address with the directedbroadcast addresses for all the subnets within the policy domain'sdefining community. The new credential is named by appending theword_Target to the rule name e.g. Ip_Broadcasts_Within_Intranet_Target.

[0311] The intradomain broadcast and multicast traffic is assigned thedisposition Monitor_Broadcasts.

[0312] Traffic between hosts in the policy domain and external hosts isdescribed by a set of rules whose complexity depends on how muchinformation the user supplied about the topology of the network.Specifically, it depends on how many perimeter elements were specifiedand on whether or not the interface addresses, i.e. MAC addresses, ofthe perimeter elements are included in the policy specification.

[0313] If there are external communities associated with at least oneperimeter element for which the interface address is not known, thewizard generates a credential combining all such communities in a singleunion unless there is only one such community, in which case itscredential already exists. This credential is named by combining thepolicy domain name with the string

[0314] External Communities, e.g. Intranet_External_Communities.

[0315] The wizard then generates two rules defining the traffic betweenhosts internal to the policy domain and these external communities. Thewizard names these rules by combining the protocol name with the domainname and the string_To_External_Communities or_External_Communities_To,depending on the direction of the IP traffic, e.g.Ip_Intranet_To_External_Communities for outbound traffic andIp_External_Communities_To_Intranet for inbound traffic.

[0316] The credentials used alternately as the initiator and targetprincipals for these rules are the policy domain's defining communityand the aforementioned credential for the external communities. Therules provisionally allow the IP traffic to flow, subject to other rulesfor higher level protocols. In the absence of a higher-level protocolwithin the network event, the rule assigns it a disposition ofDeny_Pure_Ip, i.e. its final outcome.

[0317] External communities visible through one or more perimeterelements whose interface addresses are known, are handled by a separateset of rules, two per perimeter element. For each perimeter element, thewizard starts by creating a credential that combines one or morecredentials for one or more external communities visible through it withthe perimeter element's interface address. Such credential is named bycombining the domain name with the perimeter element name and thestring_Communities. For example, external communities visible through aperimeter element named Firewall are described by a credential namedIntranet_Firewall_Communities.

[0318] The wizard then generates two rules defining the traffic betweenhosts internal to the policy domain and the external communities visiblethrough this perimeter element. The wizard names these rules bycombining the protocol name, the domain name, the perimeter element nameand the word_To, e.g. Ip_Intranet_To_Intranet_Firewall for outboundtraffic and Ip_Intranet_Firewall_To_Intranet for inbound traffic.

[0319] The credentials used alternately as the initiator and targetprincipals for these rules are the policy domain's defining communityand the aforementioned credential for the external communities. Therules provisionally allow the IP traffic to flow, subject to other rulesfor higher level protocols. In the absence of a higher-level protocolwithin the network event, the rule assigns it a disposition ofDeny_Pure_Ip, i.e. its final outcome.

[0320] Finally, if there is more than one perimeter element associatedwith the policy domain, the wizard generates rule-pairs that describethe traffic between external communities visible through specificperimeter elements as well as external communities visible through anyperimeter element, i.e. those without associated interface addresses.The rules are named by combining the names of each pair of perimeterelements with the protocol name, the policy domain name and with theword_To, in the case of addressable perimeter elements, or with thestring_External_Communities, for all other external communities. Anadditional rule is generated to cover traffic between externalcommunities not associated with an addressable perimeter element and isnamed by combining the protocol name with the domain name and the string_Between_External_Communities.

[0321] Thus, if the Intranet domain used as an example in this sectionwere to have a second (addressable) perimeter element named Router and athird non-addressable perimeter element (whose name is unimportant), thewizard would generate the following rules to cover all traffic amongsttheir respective external communities:

[0322] Ip_Intranet_Firewall_To_Intranet_Router

[0323] Ip_Intranet_Router_To_Intranet_Firewall

[0324] Ip_Intranet_Firewall_To_External_Communities

[0325] Ip_Communities_To_Intranet_Firewall

[0326] Ip_Intranet_Router_To_External_Communities

[0327] Ip_External_Communities_To_Intranet_Router

[0328] Ip_Intranet_Between_External_Communities

[0329] Table H and Table I summarize all the implicit rules andcredentials generated for the example policy domain Intranet. The policydomain includes two perimeter elements with a specified interfaceaddress (Firewall and Route, and a third non-addressable perimeterelement. TABLE H Credential Comment Intranet_Monitors Uses agentdescriptor INTRANET_MONITOR Ip_Within_Intranet_Initiator Definingcommunity plus zero-valued IP address Ip_Broadcasts_Within_IntranetCombines standard multicast _Target addresses with local broadcast anddirected broadcast addresses Intranet_External_Communities Combines allexternal communities not associated with addressable perimeter elementsIntranet_Firewall_Communities Combines all external communities visiblethrough the Firewall perimeter element Intranet_Router_CommunitiesCombines all external communities visible through the Router perimeterelement

[0330] TABLE I Credentials Disposition (I - Initiator (I - ImmediateRule T - Target) F - Final) Ip_Within_Intranet I:Ip_Within_Intranet_Initiator I: continue T: Intranet F: Deny_Pure_IpIp_Broadcasts_Within_Intranet I: Ip_Within_Intranet_Initiator I: T:Monitor_Broadcasts Ip_Broadcasts_Within_Intranet_TargetIcmp_Within_Intranet I: none (ignore) I: Monitor_Icmp T: none (ignore)Note: uses Ip_Within_Intranet as prerequisiteIp_Intranet_To_External_Communities I: Intranet I: continue T:Intranet_External_Communities F: Deny_Pure_IpIp_External_Communities_To_Intranet I: Intranet_External_Communities I:continue T: Intranet F: Deny_Pure_Ip Ip_Intranet_To_Intranet_Firewall I:Intranet I: continue T: Intranet_Firewall_Communities F: Deny_Pure_IpIp_Intranet_Firewall_To_Intranet I: Intranet_Firewall_Communities I:continue T: Intranet F: Deny_Pure_Ip Ip_Intranet_To_Intranet_Router I:Intranet I: continue T: Intranet_Router_Communities F: Deny_Pure_IpIp_Intranet_RouterTo_Intranet I: Intranet_Router_Communities I: continueT: Intranet F: Deny_Pure_Ip Ip_Intranet_Firewall_To_Intranet_Router I:Intranet_Firewall_Communities I: continue T: Intranet_Router_CommunitiesF: Deny_Pure_Ip Ip_Intranet_Router_To_Intranet_(—) I:Intranet_Router_Communities I: continue Firewall T:Intranet_Firewall_Communities F: Deny_Pure_IpIp_Intranet_Firewall_To_External_Communities I:Intranet_Firewall_Communities I: continue T:Intranet_External_Communities F: Deny_Pure_IpIp_External_Communities_To_Intra- I: Intranet_External_Communities I:continue net_Firewall T: Intranet_Firewall_Communities F: Deny_Pure_IpIp_Intranet_Router_To_External_Communities I:Intranet_Router_Communities I: continue T: Intranet_External_CommunitiesF: Deny_Pure_Ip Ip_External_Communities_To_Intra- I:Intranet_External_Communities I: continue net_Router T:Intranet_Router_Communities F: Deny_Pure_IpIp_Intranet_Between_External_Communities I:Intranet_External_Communities I: continue T:Intranet_External_Communities F: Deny_Pure_Ip

[0331] Logging and Reporting Modules

[0332] The preferred embodiment of the invention provides logging andreporting modules, as described herein with reference to FIG. 1a. As thepolicy engine module 102 reaches dispositions on network events, itpasses the network event object to the logging module 103.

[0333] The preferred embodiment of the invention also provides an alarmscript 155. As the policy engine module 102 reaches dispositions onnetwork events of a certain disposition severity, for example, CRITICALor HIGH, the alarm script is invoked to provide expedited alerting ofthe disposition.

[0334] The following algorithm is used to enter the data into thedatabase 104.

[0335] During initialization of the logging module 103, the database 104is tested to see if it contains a policy that matches the MD5 hash ofthe policy 105 currently being used by the policy engine 102. If no suchpolicy is found then the policy details are added to the database 104;

[0336] with each network event passed to the logging module 103, iflogging of network events is enabled, then:

[0337] if the final disposition of the network event matches one of thelist of dispositions that is to be logged, then:

[0338] add the network event to the buffer of network events, flushingthe buffer to the database 104 if it is full;

[0339] loop through each of the protocol events contained in the networkevent;

[0340] if the initiator and responder principals have not been alreadyadded to the database 104 then do so, caching the database keys forlater use; and

[0341] add the protocol event to the buffer of network events, flushingthe buffer to the database 104 if it is full.

[0342] On a periodic basis report statistics 161 are sent across asecure channel to a secure, customer accessible server 162. Thepreferred embodiment of the invention uses the following algorithm.

[0343] A report script 160 described is used to generate a report 161for the configured or predetermined time period. An example of a list ofpreferred acquired or calculated statistics or intermediate steps iscontained in Table J below;

[0344] The report 161 is then packaged using the tar command and PGP toencrypt the resulting file using the public key of a recipient emailaccount; and

[0345] This encrypted file is then emailed to the recipient emailaccount.

[0346] It should be appreciated that an equally preferred embodimentperforms name resolution on packet data after the packet data has beencollected, rather than concurrent with collecting the packet data. Anadvantage to such name resolution technique is that name resolutionafter collection is removed from real-time processing, thereby renderingname resolution more efficient.

[0347] On the receiving secure server 162 the following algorithm isinvoked on the received email message.

[0348] PGP is used to decrypt the received encrypted tar file;

[0349] Tar is used to extract the report data;

[0350] The report data is then processed to link the report into thereporting website 164 for the client; and

[0351] Any supplied protocol event data is then stored in a reportingdatabase 165.

[0352] Upon accessing the reporting website 164 the client is able toperuse the reports that have been generated, access the protocol eventdata stored in the database 165 via a cgi script.

Table J

[0353] Generate network events in subsidiary web files, based onexecution run;

[0354] Generate network events table,

[0355] Generate table for URL's and status codes;

[0356] Find events of interest;

[0357] Check for all execution runs being in sequence;

[0358] Give best optimization for queries;

[0359] Compute number of events and number of exceptions;

[0360] Apply definitions of log severity and disposition code in orderof criticality;

[0361] Apply query to several execution runs at a time, collect results;

[0362] Select key disposition and key policy rule first, to be able tofind distinct disposition and policy rule;

[0363] Determine sort order for disposition and policy rule table; and

[0364] Generate a list of dispositions in the selected events, countinghow many events were generated by each.

Automated Generation of an English Language Representation of a FormalNetwork Security Policy Specification

[0365] The preferred embodiment of the invention uses a formalspecification of network security policy that is to be enforced on anetwork. This specification provides a precise, compact description ofnetwork security policy. However, it is difficult for a layperson tounderstand. In order to allow comprehension of the policy bynon-technical staff within a user's organization the parser module (FIG.1 150) is used to generate an English language description of thepolicy. This description is simple enough to be understood, yet capturesthe salient details of the policy. It will be appreciated that theinvention generated a representation in a human readable language, suchas english, those skilled in the art will recognize that the inventionmay generate representations in any human readable language.

[0366] The preferred embodiment of the invention provides the followingalgorithm for generating the English language representation. Thealgorithm comprises the following:

[0367] Loading the policy into the parser from its text representation;and

[0368] Looping through all supported protocols, from the highest levelprotocols to the lowest;

[0369] Sorting the rules for this protocol into ranked order; and

[0370] Looping through these rules from the highest ranking to thelowest;

[0371] Generating a text description of the rule using the algorithmbelow. If an HTML flag has been set then format the text into a HTMLtable; and

[0372] Append this description to a collection of descriptions alreadygenerated.

[0373] The preferred embodiment of the invention provides the followingrule algorithm to generate an English language representation of asingle policy language rule. The algorithm is described with referenceto FIG. 12. The algorithm outputs the name of the rule at hand (2001).It then proceeds to output the agent's name (2002), where the agent isthe subject network monitor(s) to which the policy applies. Thealgorithm then loops through all protocol and action combinations(2003). If the action is to be ignored (2004), then the rule applies tothe whole protocol (2005). Otherwise, the rule applies to certainactions only (2014). The algorithm then looks at the immediate outcomefor the rule (2006). The algorithm then outputs the correspondingdirective for the outcome (2007). If any conditions exist on thedisposition, then the algorithm outputs the conditions (2008). Thealgorithm looks at the final outcome (2011), then outputs thecorresponding final outcome of the rule (2012). If any conditions existon the disposition, then the algorithm outputs the conditions (2013). Ifthe rule applies to a particular initiator or target, then the algorithmoutputs the initiator or target name (2009). Otherwise, the algorithmoutputs a general inclusive name, such as, for example, “anyone.” Thealgorithm then checks for prerequisites (2010). If any are discovered,the algorithm then outputs such prerequisites.

[0374] For an example of the rule algorithm discussed above, Table Kbelow shows code to the example implementation. Table K if (isBuiltin())return, Bool processedImmediate = false; Bool immediateDefaultContinue =false; Bool capitalize = true; string str; string protocol; //output thetable row start if (html) str = “\n<tr><p>”; else str =“\n\n”; //outputthe rule name if (html) str += “<TD WIDTH=\”10%\“VALIGN=\”TOP\“><B>” +getName() + “<a name = \”“ + getName() + ”\“></a></B></TD>”; else str +=“Rule ” + getName() + “:”; //output the agent name string agentName; if(getAgent() == 0) agentName = “All Monitors”; else agentName =getAgent()->getName(); if (html) str += “<TD WIDTH=\”5%\“VALIGN=\”TOP\“>” + agentName + “<TD>”; //start the cell for thedescription if (html) str += “<TD WIDTH=\”85%\“ VALlGN=\”TOP\“>”; //loopthrough the protocol and action combinations Bool first = true; for(PrsUnion::const_iterator t0 =_protocol->begin(); t0 !=_protocol->end();t0++) { for (PrsUnion::const_iteratort2 =_action->begin(); t2!=_action->end(); t2++) { if (first) first = false; else protocol +=“,”; //if the action is ignore then it applies to the whole protocol if((*t2)->getStringRepresentation() != PrsConst::META_IGNORE) protocol+=(*t0)->getStringRepresentation() +“-” +(*t2)->getstringRepresentation() +“”; else protocol +=(*t0)->getStringRepresentation() +“”; } } //look at the outcome tofigure what we do with this traffic //is there an immediate clause if(_immediate != 0) { //output text based on the code string code=_immediate->getDefault()->getCode(); if (code == PrsConst::DISPCODE_OK){ capitalize ? str += “Allow” : str += “allow”; capitalize = false; }else if (code == PrsConst::DISPCODE_CONTINUE) { if(_final->getDefault()->getCode() == PrsConst::DISPCODE_OK) capitalize ?str += “Provisionally allow” : str += “provisionally allow”; else if(_final->getDetault()->getCode() == “POLICY_ERROR”) //say nothing...this is the default else capitalize ? str += “Provisionally deny” : str+=“provisionally deny”; immediateDefaultContinue = true; } else {capitalize ? str += “Deny” : str += “deny”; capitalize = false; } str +=protocol; if ((_immediate->getGuards()) != 0 &&(_immediate->getGuards()->size() != 0)) /* KGS &&!immediateDefaultContinue */ { if (_immediate->getGuards()->size() == 1)str += “with condition (”; else str += “with conditions (”; first =true; for (std::vector<PrsGuardedDisposition*>::const_iteratorcond=_immediate->getGuards()- >begin(); cond!=_imniediate->getGuards()->end(); cond++) { if (first) first = false;else str += “,”; if (html) str += “<|>”; str +=(*cond)->getGuard()->getName(); if (html) str +=“<|>”; } str +=“)”; }processedImmediate = true; } //is there a final clause if (_final != 0){ if (!processedImmediate) { //output text based on the code string code=_final->getDefault()->getCode(); if (code == PrsConst::DISPCODE_OK) {capitalize ? str += “Provisionally allow” : str += “provisionallyallow”; capitalize = false; } else if (code == “POLICY_ERROR”) //saynothing... this is the default else { capitalize ? str += “Provisionallydeny” : str += “provisionally deny”; capitalize = false; } str +=protocol; if ((_final->getGuards()) != 0 && (_final->getGuards()->size()!= 0)) { if (_final- >getGuards()->size() == 1) str += “with condition(”; else str += “with conditions (”; Bool first = true; for(std::vector<PrsGuardedDisposition*>::const_iterator cond=_immediate->getGuards()- >begin(); cond!=_immediate->getGuards()->end(); cond++) { if (first) first = false;else str += “,”; if (html) str += “<|>”; str +=(*cond)->getGuard()->getName(); if (html) str += “<|>”; } str += “)”; }} else { //output text based on the code string code=_final->getDefault()->getCode(); if (!immediateDefaultContinue) { if(code == PrsConst::DISPCODE_OK) str += “but provisionally allow”; elseif (code == “POLICY_ERROR”) ;//say nothing... this is the default elsestr += “but provisionally deny”; } if ((_final->getGuards()) != 0 &&(_final->getGuards()->size() != 0)) } str += “with conditions (”; Boolfirst = true; for (std::vector<PrsGuardedDisposition*>::const_iteratorcond =_immediate->getGuards()- >begin(); cond!=_immediate->getGuards()->end(); cond++) { if (first) first = false;else str += “,”; if (html) str += “<|>”; str+=(*cond)->getGuard()->getName(); if (html) str+= “<|>”; } str += “),”;} } } if (html) str += “from <|>” + (_initiator->getCredential() ?_initiator->getCredential()->getName() : “anyone”) + “<|> to <|>” +(_target->getCredential() ? _target->getCredential()->getName() :“anyone”) + “<|>”; else str += “from” + (_initiator->getCredential() ?_initiator->getCredential()->getName() : “anyone”) + “to” +(_target->getCredential() ? _target->getCredentialO()->getName() :“anyone”); if (getPrerequisite() != 0) { str += “, provided that”; Boolfirst = true; for (vector<const PrsRule*>::const_iterator t3=_prerequisite->begin(); t3 !=_prerequisite->end(); t3++) { if (first)first = false; else str +=“or”; if (html) str += “<|><a href=\”#“ +(*t3)->getName() + ”\“>” + (*t3)->getName() + “</a></|>”; else str +=(*t3)->getName(); } str += “is true”; } //start the cell for thedescription it (html) str += “</TD></TR>”; else str += “ (Agent” +agentName +“).”; ostm << str.c_str();

[0375] For an example of an output file generated by the main algorithmdiscussed above, Table L shows the example of the output in tableformat. For an example of a policy specification file that can be usedas input into the main algorithm discussed above, refer to Table Pbelow. TABLE L Rules for protocol HTTP Http_Blocked_Service_ViolationAll Deny HTTP from anyone to anyone, Monitors provided that Tcp BlockedServices is true. Http_Deny All Deny HTTP from anyone to anyone MonitorsRules for protocol FTP Ftp_Blocked_Service_Violation All Deny FTP fromanyone to anyone, Monitors provided that Tcp Blocked Services is trueFtp_Deny All Deny FTP from anyone to anyone MonitorsFtp_Anonymous_Authentication All Allow FTP-CONTROL_AUTHENTICATE Monitorswith condition (Authentication_Rejected), from Anon_User to anyoneFtp_Validate_Password All Allow FTP-CONTROL_AUTHENTICATE Monitors withconditions (Authentication_Rejected), ~ Strong_Password), from anyone toanyone Ftp_Ignore_Data_Connections All Allow FTP-DATA_OPEN from anyoneto Monitors anyone Rules for protocol SSH Ssh_Validate_Handshake AllAllow SSH-HANDSHAKE, SSH- Monitors SESSION_ABORTED with conditions(Ssh_Authentication_Failed, Ssh_Secure_Authentication_Modes), fromanyone to anyone Ssh_Blocked_Service_Violation All Deny SSH from anyoneto anyone, Monitors provided that Tcp Blocked Services is true. Ssh_DenyAll Deny SSH from anyone to anyone Monitors Rules for protocol SSLSsl_Validate_Handshake All Allow SSL-HANDSHAKE with conditions Monitors(Authentication_Rejected, Ssl_Session_Qos), from anyone to anyoneSsl_Blocked_Service_Violation All Deny SSL from anyone to anyone,Monitors provided that Tcp Blocked Services is true. Ssl_Deny All DenySSL from anyone to anyone Monitors Ssl_Missed_Handshakes All AllowSSL-MISSED_HANDSHAKE from Monitors anyone to anyone Rules for protocolTCP Tcp_Blocked_Services_Response All Deny TCP-ABORT, TCP-CLOSE, TCP-Monitors TIMEOUT with condition (Tcp_Data_Xfer), from anyone to anyone,provided that Tcp Blocked Services is true. Tcp_Connection_TerminatedAll Allow TCP-ABORT, TCP-CLOSE, TCP- Monitors TIMEOUT from anyone toanyone Tcp_Deny All Provisionally deny TCP from anyone to Monitorsanyone Tcp_X_Shh_From_Clouds_To_Cgi_Provisional X_Monitors Provisionallyallow TCP-CONNECT from Clouds toTcp_X_Shh_From_Clouds_To_Cgi_Provisional_Target Tcp_X_Spm_Colloc_TrafficX_Monitors Allow TCP-CONNECT from Modin toTcp_X_Spm_Colloc_Traffic_Target Tcp_X_Spm_Colloc_Traffic_ProvisionalX_Monitors Provisionally allow TCP-CONNECT from Modin toTcp_X_Spm_Colloc_Traffic_Provisional_TargetTcp_X_Ssh_From_Monkey_To_Fluffy_Provisional X_Monitors Provisionallyallow TCP-CONNECT from Monkey toTcp_X_Ssh_From_Monkey_To_Fluffy_Provisional_TargetTcp_X_X_Loghost_Traffic X_Monitors Allow TCP-CONNECT from X_Web_Serversto Tcp_X_X_Loghost_Traffic_Target Tcp_X_Dns_From_Colloc_To_Dns_ServerX_Monitors Allow TCP-CONNECT from X_Coloc_Subnet toTcp_X_Dns_From_Colloc_To_Dns_Server_Target Tcp_X_Port_1984_TrafficX_Monitors Allow TCP-CONNECT from X_Coloc_Subnet toTcp_X_Port_1984_Traffic_Target Tcp_X_Ssh_To_Web_Server X_Monitors AllowTCP-CONNECT from X_Ssh_To_Web_Server_Initiator toTCP_X_Ssh_To_Web_Server_TargetTcp_X_Ssh_From_Fluffy_To_Monkey_Provisional X_Monitors Provisionallyallow TCP-CONNECT from Fluffy toTcp_X_Ssh_From_Fluffy_To_Monkey_Provisional_TargetTcp_Ssh_From_X_To_X_Web_Servers_Provisional X_Monitors Provisionallyallow TCP-CONNECT fromX_Ssh_From_X_To_X_Web_Servers_Provisional_Initiator toTcp_X_Ssh_From_X_To_X_Web_Servers_Provisional_TargetTcp_X_Http_From_Any_To_All_Web_Servers_Provisional X_MonitorsProvisionally allow TCP-CONNECT from anyone toTcp_X_Http_From_Any_To_All_Web_Ser vers_Provisional_TargetTcp_X_Stmp_From_All_To_X X_Monitors Allow TCP-CONNECT fromX_Stmp_From_All_To_X_Initiator to _Smtp Tcp_Blocked_Services AllProvisionally deny TCP-CONNECT from Monitors anyone to anyoneTcp_Missed_Connections All Allow TCP-MISSED_CONNECT from Monitors anyoneto anyone Tcp_Blocked_Services_Violation All Deny TCP-PROTOCOL_UNKNOWNfrom Monitors anyone to anyone, provided that Tcp Blocked Services istrue. Tcp_Unknown_Protocol All Deny TCP-PROTOCOL_UNKNOWN from Monitorsanyone to anyone Rules for protocol UDPUdp_X_Dns_From_Colloc_To_Dns_Server X_Monitors Allow UDP-ASSOCIATIONfrom X_Coloc_Subnet to Udp_X_Dns_From_Colloc_To_Dns_Server_TargetUdp_Deny All Deny UDP from anyone to anyone Monitors Rules for protocolICMP Icmp_Within_X X_Monitors Allow ICMP-ASSOCIATION from anyone toanyone, provided that Ip Within X is true. Icmp_Deny All Deny ICMP fromanyone to anyone Monitors Rules for protocol IPIp_Directed_Broadcasts_Within_X X_Monitors Allow IP-ASSOCIATION fromIp_Within_X_Initiator to Ip_Directed_Broadcasts_Within_X_TargetIp_External_Communities_To X X_Monitors Provisionally denyIP-ASSOCIATION from X_External_Communities to X_Coloc_SubnetIp_X_To_External_Communities X_Monitors Provisionally denyIP-ASSOCIATION from X_Coloc_Subnet to X_External_Communities Ip_Within_XX_Monitors Provisionally deny IP-ASSOCIATION from Ip_Within_X_Initiatorto X_Coloc_Subnet Ip_Non_Directed_Broadcasts_Within_X X_Monitors AllowIP-ASSOCIATION from IP_Within_(—l X)_Initiator to_Generic_Multicast_And_Broadcast_(—l Addresses) Ip_Deny All Deny IP fromanyone to anyone Monitors Ip_Unknown_Protocol All DenyIP-PROTOCOL_UNKNOWN from Monitors anyone to anyone

Algorithm for Efficient Rule Evaluation

[0376] The preferred embodiment of the invention comprises a techniquefor a policy engine internally to organize policy rules in order toeffect an efficient evaluation of protocol events at runtime. Evaluationof a protocol event entails selecting one or more applicable policyrules using an evaluation algorithm. The preferred evaluation algorithmis described in A Declarative Language for Specifying a Security Policy,U.S. patent application Ser. No. 09/479,781 (Jan. 7, 2000). An excerptdescribing the preferred evaluation algorithm is provided below in TableQ.

[0377] Using this technique, policy rules are organized in a manner thatminimizes the number of rules that need to be considered whendetermining the set of rules applicable to a given protocol event. Thealgorithm is described with reference to FIG. 13 as follows:

[0378] Create a first associative array, such as, for example,agent-to-protocols, where the key is an agent descriptor and the valueis a reference to a second associative array with all the policy rulesapplicable to network traffic monitored by that agent (3001);

[0379] Create a second associative array, such as, for example,protocol-to-actions, where the key is a protocol name and the value is areference to a third associative array with all the policy rulesapplicable to that protocol (3002).

[0380] Create a third associative array, such as, for example,action-to-rules, where the key is a protocol action and the value is alist of references to the policy rules applicable to that protocolaction (3003). The rules referenced in this list (3004) are sorted indecreasing order of rank number, taking into account any constraintssuch as, for example, rank-above, that might be present. Rules with thesame rank number are ordered in the lexical order of their names.

[0381] It should be noted that the same rule can be referenced bydifferent lists of ordered rules and, in each list, can have differentrank numbers because the ranking of a rule is relative to the ranking ofthe other rules in the same list.

Assessment Tool

[0382] The preferred embodiment of the invention provides an assessmenttool that allows the discussed technique for continuously assessing thesecurity of a system to be applicable to both long-term and short-termnetwork assessment. The tool provides an additional dimension to networkassessment. That is, it provides the ability to capture and classifylarge volumes of network traffic efficiently, based on a formal policywhich describes permitted traffic. The tool adds network usage to theknown list of features discussed in an assessment framework.

[0383] It has been found through field experience that the invention canbe useful in the following contexts:

[0384] Identifying services that were not mentioned by the systemadministration staff of a network that is being assessed;

[0385] Identifying usage patterns of critical machines. In an assessmentframework, this applies to typical usage patterns, because a long-termdeployment of the invention is needed to continuously analyze andmonitor changes in usage or rare aberrant behavior;

[0386] Identifying services; and

[0387] Analyze routing patterns. It should be appreciated that subnetsare not scanned.

[0388] It should be appreciated that using the invention as asupplemental process in performing network assessments results in atleast the following benefits:

[0389] Rather than providing an inference of possible network behaviorthat is based on what hosts are configured to do, the network behavioris directly analyzed based on direct observation of data traffic;

[0390] Rather than basing security analysis on a static snap-shot of thenetwork environment as it existed at a particular moment, the analysisis based on a dynamic recording of network behavior over somenon-trivial amount of time. As an analogy, traditional known networkvulnerability scans take still photographs, while the invention takes amotion picture;

[0391] Instead of relying on the accuracy of information provided by thecustomer point of contact through an interview process, the inventionprovides specific and tangible data points for discussion thatfacilitates the interview process and educates the customer on problemsin an immediate feedback loop; and

[0392] Because the invention is policy based, and because of the rigorbuilt into the policy language and analysis engine, the otherwise manual(and hence error prone) analysis of security issues relative to thebusiness and architectural context are enforced with a precisemethodology which greatly reduces errors and omissions during theassessment process.

[0393] It should be appreciated that because the invention operatespassively, the customer network can be monitored while in normaloperation or production.

[0394] Operational Description

[0395] An example of implementing the assessment tool is described inthe following discussion. A consultant arrives at a customer office withone or more workstations with the monitoring invention discussed hereinloaded. The workstation, or station for short, may be a laptop computer,or other suitably portable platform. The monitoring station is attachedto the customer network at a critical network bottleneck, e.g. justinside an Internet firewall, and monitors all traffic at that point inthe network. From a security point of view, the monitoring station isentirely passive and invisible to the network. The monitoring stationonly receives packets and does not respond to any protocol actions. Dueto the monitoring station's passive nature, no operational impact isimposed on the subject network. Hence, assessments may be performedduring peak production times, as well as when a network is in aquiescent state.

[0396] In this example, the monitoring station is left attached to thenetwork for a long period of time, depending on conditions, such as, forexample, the practical demands of the visit, storage space on thestation, and the amount of traffic on the customer's network. Ifappropriate, the station can be left at the customer site to gather dataover a short-term period, such as, for example, days and weeks.

[0397] In this example of an assessment situation, the policyspecification is used to remove from consideration as much mundanenetwork traffic as possible, allowing the analyst to concentrate on moreinteresting traffic. Due to the opinion of the analyst being part of theassessment process, there is no fixed goal for the level of detailneeded in the policy specification. In the simplest case, the analystgenerates no policy at all, and examines the network events one by one(perhaps using the query tool to filter them). In practice, it can besuggested that the analyst undergoes a short policy development phase,as the short policy development phase can serve the analyst well toreduce thousands of network events into a page or two, which may then beexamined by inspection.

[0398] The invention allows data to be stored in full packet form formost detailed analysis, or in compressed form storing onlysecurity-sensitive events. The latter form also removescustomer-confidential information, such as, for example, embeddedpasswords, so that it is more appropriate for removal from the customersite. A typical usage scenario is capturing full-packet data in a shortburst, such as, for example, five minutes. After a brief analysis, alonger data collection is run using the compressed form.

[0399] The preferred embodiment of the invention provides the followingalgorithm for an operator, such as an analyst, to perform the dataanalysis on a data packet or on a compressed file of data. The algorithmis described referring to FIG. 14, as follows:

[0400] 1) Create a null policy, which denies all actions, for a customersite (copying a file). Set null policy to the current policy (4002);

[0401] 2) Run the policy engine discussed herein over the input data andusing current policy (4002), and store the resulting data in a localdatabase (4003);

[0402] 3) Using the query tool discussed herein, examine the networktraffic that is declared in violation by the current policy (4004);

[0403] 4) Categorize the most frequent traffic based on customer input:

[0404] a) If the traffic matches known customer-supplied input patterns,add this traffic to the policy with an OK disposition (4005);

[0405] b) If the traffic does not match customer-supplied inputpatterns, but has high volume, add this traffic to the policy with anOK,monitor disposition (4006).

[0406] 5) Repeat from step 2 (4009) until only a small, manageablenumber of events remains (4007). Then end the algorithm (4008).

[0407] It should be appreciated that the same packet or compressed fileis run by the policy engine multiple times.

[0408] It should be appreciated that in an assessment situation a policycan be edited by using the policy generator discussed herein. Theinvention provides for using the policy generator for rapid policydevelopment based on transport-level parameters. Enhanced policydevelopment, using more complex tools, typically is not necessary in anassessment situation.

[0409] It should also be appreciated implementing the algorithmdiscussed above does not take very long. Part or all of the process maytake place at the customer site, in a hotel room, on an airplane, orback at the analyst's office, for example. When the process iscompleted, the analyst has a list of monitored network events. This listis used as a basis for additional discussion with the customer todetermine the meaning of such events. Experience has shown that suchconversation is useful to the assessment interviewing process.

[0410] It should also be appreciated that the variations of thealgorithm above can be implemented and are within the scope of theinvention. Examples of variations follow.

EXAMPLE VARIATION I

[0411] An equally preferred embodiment comprises the analysts firstdetermining the customer requirements and the customer networkcredentials. Using this information, the analyst programs an initialpolicy. The analyst can derive and use additional information from thescanning process as described in the algorithm above.

EXAMPLE VARIATION II

[0412] The customer or analysts designs an initial best policy as a setof credentials and rules, set all dispositions to DENY, and monitors thenetwork to determine what the dispositions should be.

Credential/Condition Assertion Verification Optimization

[0413] In the preferred embodiment of the invention, the policy languagedescribes a policy decision involving two principals, an initiator and atarget principal. These principals are identified by a set of one ormore credentials. For each policy decision the policy engine ascertainswhich credential in the policy best describes the information about theprincipals involved in an interaction. Similarly, the policy languageherein describes conditions that in turn describe tests performed on thestate of an associated protocol event.

[0414] The preferred embodiment of the invention provides acredential/condition assertion verification optimization algorithm toensure that the choice of credentials and conditions are made asefficiently as possible.

[0415] To accomplish credential/condition assertion verificationoptimization, the policy engine:

[0416] During the initialization process dynamically creates comparingfunctions for principals with credentials, and comparing functions forstate of protocol events with particular conditions in a high levellanguage such as C++;

[0417] Dynamically creates and loads a module containing the comparingfunctions;

[0418] During runtime ensures that installed policy file matches modulecontaining comparing functions, otherwise generates new modulecontaining comparing functions that correspond to installed policy file;and

[0419] Calls comparing functions as appropriate.

[0420] The preferred embodiment provides a more rigorous algorithm, anexample of which is described in Table M below.

Table M

[0421] During the initialization process of the policy engine:

[0422] the policy engine requests that the parser module load a policyfile, comprising credentials and conditions into an in-memoryrepresentation;

[0423] the policy engine requests that the parser module load anassertion verification dynamically loadable library (DLL);

[0424] if this DLL exists then

[0425] it is loaded into memory; and

[0426] a predetermined function, for example named dIIValidateFunc( ),contained in the loaded DLL is called. If the return value of thefunction call is the same as a MD5 hash of the previously loaded policyfile, then loading is complete. Otherwise execution initializationcontinues below;

[0427] because the DLL does not exist or because the MD5 hash does notmatch, a code generation function of the parser module is invoked,which:

[0428] adds header information to a C++ assertion code file;

[0429] adds a function that returns the MD5 hash of the policy file thatwas used to generate this C++ file;

[0430] iterates through credentials contained in the in-memoryrepresentation, generating C++ function prototype and functiondeclarations for code that can compare a principal description with thedefinition of a credential into the assertion code file, wherein suchcomparison is performed by:

[0431] calling other credential comparison methods for any credentialsused in the definition of the credential under test;

[0432] making calls to the policy engine module to perform comparisonoperations based on allowable operations for the built-in types of thepolicy language; and

[0433] combining the results of the above tests with logical operatorsAND, OR and NOT;

[0434] iterates through the conditions contained in the in-memoryrepresentation, generating C++ function prototype and functiondeclarations for code that can compare a protocol state description withthe definition of a condition into the assertion code file, wherein suchcomparison is performed by:

[0435] calling other condition comparison methods for any conditionsused in the definition of the condition under test;

[0436] making calls to the policy engine module to perform comparisonoperations based on the allowable operations for the built-in types ofthe policy language; and

[0437] combining the results of the above tests with logical operatorsAND, OR and NOT;

[0438] compiles and links this generated C++ file to create adynamically loadable module containing a compiled version of theprincipal/credential and protocol/condition comparison functions; and

[0439] loads this newly created module.

[0440] During the runtime of the policy engine:

[0441] each time that it needs to decide whether a principal isdescribed by a particular credential it computes the name of thecomparison function based on the name of the credential to be tested;

[0442] calls the comparison function which returns a Boolean value thatrepresents whether the credential under test matches the principal undertest;

[0443] each time that it needs to decide whether a protocol statesatisfies a particular condition it computes the name of the comparisonfunction based on the name of the condition to be tested; and

[0444] calls the comparison function which returns a Boolean value thatrepresents whether the condition under test satisfies the protocol stateunder test.

Network Monitor Internals Descriptions

[0445] The preferred embodiment of the invention provides a networkmonitor internals mechanism discussed below that serves to translatepacket data into multiple concurrent streams of network event data. Itaccomplishes this by interpreting both sides of each protocoltransaction.

[0446]FIG. 15 shows a high level schematic diagram of the networkmonitor 127 accepting packet data from either a live network interface125 or a file containing packet data 126. The network monitor extractssecurity-sensitive details from the input packet stream 125, 126, andgenerates output in a serialized stream of encoded network eventinformation 115. The preferred encoded format is DME encoded format,discussed below in section, Network Event Encoding Format. The outputnetwork event information can be stored for logging or debuggingpurposes, or can be passed directly to the policy engine. Thus, thediscussed network monitor provides an efficient process of exportingdata from a customer's site, such process comprising extractingsecurity-sensitive information.

[0447]FIG. 16 shows a schematic diagram of process flow according to theinvention. The network monitor 127 is a single-threaded program thatprocesses packets (125 or 126) as they are read. Each packet is passedto a monitor protocol engine 6100 for processing. Whensecurity-sensitive protocol events are encountered in the packet data,the monitor calls into its output section 6200 to transmit network orprotocol events to the rest of the policy monitoring system 100 via anetwork pipe, direct procedure call. Output section 6200 can also storeprotocol events in a file for later processing.

[0448] Protocol Engine

[0449] The preferred embodiment of the invention provides a protocolengine in the network monitor that can be described with reference toFIG. 17, which is a block schematic diagram of features of the protocolengine according to the invention. Input packet data 115 is read into aknown object-oriented structure type 6101, such as, for example, a Cstructure here named pkt_t structure. The pkt_t structure 6101represents a packet on the network. It provides a stack-basedstructuring mechanism 6102 that allows protocol headers and trailers6103 to be marked in the packet so that software may focus easily on thecorrect protocol layer. The pkt_t structure 6101 also includes genericsrc 6104 and dst 6105 address locations, and flags 6106 to pass usefulinformation up and down a connection stack, for example, if such packetis transiting from server to client or vice versa.

[0450] The protocol engine 6100 provides one module 6107 for eachprotocol implemented 6108. The modules implement a generic series ofoperations, a preferred example of such series is provided below inTable N. A common connection structure 6109 allows connection data to bearranged in a stack allocation for each access across layer boundaries.In Java or C++ terminology, for example, each protocol is a superclassof connection. The layering permits protocols to assume one or moreroles as the layer responsible for each corresponding boundary, such as,for example: Network, Transport, Session, Application, or Transactions.TABLE N Example of generic operations for each protocolimplementation: 1. Init: Call-once initialization 2. Bind(packet,connection): given the first packet of a connection, attempt to bindthis packet into a new instance of this protocol within connection.Establish the instance in its proper role(s) within the connection. 3.Input(packet, connection): given a packet, which has been associatedwith a connection (in some cases, connection is NULL, indicating that nosuch relationship exists, or exists yet), process the packet as input tothe connection. 4. GiveBack(packet, connection): given a packet, whichhas been associated with a connection at a higher level of protocol,give back the packet to this layer, so that the data will be receivedlater, as if it was retransmitted. Typically, packet has been modifiedto contain only part of the input data. 5. GetMore(connection,amountNeeded, fromClientOrServer) returns(packet): given a connection,attempt to return a packet containing more data on the connection, ifsuch is available. This call is used from a higher layer of protocolcalling down to a lower layer of protocol. The fromClientOrServerargument is used to determine if the data is being requested that wasreceived by the server side or the client side of the connection. 6.StopCollecting(connection): given a connection, adjust the protocolstack so that no further data will be processed on this connection.Depending on the protocol in question, this may involve discarding dataor adjusting filters. A connection which is not “collecting” attempts toprocess packets in the most efficient manner. 7. Shutdown(connection,fromOrg, fromDst): given a connection, modify the connection state toindicate that the client, server, or both have acted to take down theconnection. The full generality of the call is needed only for atransport connection like TCP. 8. Del(connection): given a connection,arbitrarily delete the instance of this protocol from the connectionobject. This call is intended to clean up the resources used by theconnection; Shutdown is used to indicate protocol agreement that theconnection is coming to an end. 9. Alarm(connection, time): given aconnection and the current time, this call is used to signal an alarmhas expired on this connection. The time argument is the official timeof the alarm, which may not even be related to the current time. 10.SwitchSrcDst(connection): this call indicates that a higher layer ofsoftware (perhaps a higher level protocol) has determined that thechoice of client and server in this protocol instance are wrong, andshould be reversed. This may happen when initial connection negotiationpackets are not seen by the monitor, but later information makes theclient and server clear.

[0451] It should be appreciated that in the stopCollecting genericoperation, and in a transport protocol, header information in packetsmay need to be examined to determine connection state, allowing freeingof resources when the connection terminates. Transport protocols discardall subsequent data from the connection, and do not forward packets onto higher level protocols. Such mechanism allows the monitor toefficiently process bulk transfers, encrypted connections, orconnections that are no longer of interest to the policy engine.

[0452] It should be appreciated that the process discussed above for thestopCollecting generic operation can be appropriate for a hardwarefilter to stop packets from arriving.

[0453] The concept of the current time in the monitor flows from thepacket level upwards. That is, time is associated with the packet and ismaintained throughout the packet. When the network monitor is running inreal time off live packet data, current time reduces to the time apacket was received, which may be earlier than the time when the packetis processed. When the network monitor is running off stored packetdata, current time in the monitor has no relation to actual currenttime. The packet is processed relative to the time it was received andwhereby time intervals remain the same. Also, results can be lined up inthe database reflecting the point of reference of the time the packetwas received.

[0454] The network monitor provides support for setting alarms onconnections. An alarm is set by registering a connection to receive asignal when the network monitor transitions to a predetermined value ofcurrent time. The signal consists of a call to a generic alarm operationin every protocol layer registered with such connection. Alarm handlersare called in order from lowest protocol layer to highest protocollayer.

[0455] Because network monitor functionality is based on network eventsthat can map to network connections, the network monitor provides aconnectionless association feature. By using the feature, the networkmonitor registers the fact that it noticed two IP hosts communicating.Typically, an association is long lived, whether or not the networkmonitor knows its intention. Examples of associations are a series ofICMP PING/PING REPLY packets and a stream of IPSEC packets. The networkmonitor treats associations as connections. Indeed, often associationsare connections at a higher level of protocol.

[0456] Output Section

[0457] The preferred embodiment of the invention provides an outputsection in the protocol engine. FIG. 18 is a high level flow diagram ofthe preferred output section according to the invention. The outputsection 6200 of the network monitor receives network event data from theprotocol engine and generates outbound calls 6203 to transmit such datato the policy engine or to a file.

[0458] The output section 6200 works by allowing the network monitor toestablish a transaction which forms an association between a monitorconnection and a network event in the policy engine. FIG. 19 shows aschematic diagram of a transaction 6204, comprising an association 6205between a subject monitor connection 6206 and a network event 6207.Typically, the lifetime of the connection 6206, the transaction 6204,and the network event 6207 is similar.

[0459] The output section's interface comprises a set of calls toestablish communication with the policy engine, and to start and finishtransactions, and a set of protocol-specific calls. The calls progressas follows:

[0460] Connect

[0461] BeginTransaction

[0462] ProtocolEvent1

[0463] ProtocolEvent2

[0464] . . .

[0465] EndTransaction

[0466] Disconnect

[0467] It should be appreciated that in addition to the calls above,multiple transactions can be active at a time, as long as eachtransaction follows the ordering described above.

[0468] The output section internally translates such calls into ageneric set of calls, an example of which is listed below. Atinitialization of the network monitor, the output section is configuredwith a chain of output generic modules, each of which is used as filteron the output data. An example of the implemented modules follows:

[0469] NULL: acts as an endpoint, but discards input data without doinganything;

[0470] SM: connects by procedure call directly to policy processing;

[0471] ENC: generate encoded form of output; and

[0472] LOG: generate textual form of output.

[0473] In an equally preferred embodiment of the invention, the networkmonitor also includes an input section that decodes an encoded versionof events. For an example application, in a real-time monitoring systemembodiment the monitor 127 processes network traffic 125 in real timeand uses ENC to generate encoded output. The encoded output istransmitted in real-time over a TCP connection where it is decoded andconnected using SM to the Policy Engine 102.

[0474] In another embodiment of the invention, the output section isused for testing purposes. The output section is configured usingcommand line arguments. An example of an algorithm for such testingfollows:

[0475] 1. Capture packet data into a file;

[0476] 2. Run the network monitor on the packet data, using LOG→ENC.Store the logged textual data and the encoded form into separate files;and

[0477] 3. Run the network monitor on the encoded data, using LOG→NULL.Store the logged textual data in a file.

[0478] 4. Compare the two textual files to make sure that the decodedversion matches the logged textual file.

[0479] Network Event Encoding Format

[0480] The preferred embodiment of the invention provides a techniquefor network event encoding to be used by the network monitor. Theencoding technique is designed for both archival and transmissionpurposes. The basic format of the encoding is:

[0481] Header

[0482] Embedded agent descriptors

[0483] Type map

[0484] Encoded transactions

[0485] An example of the preferred form of the header follows:

[0486] 4 byte magic number: “SMKo”

[0487] 1 byte major version=2

[0488] 1 byte minor version=1

[0489] 4 bytes containing the size of this header

[0490] 8 bytes (struct timeval) begin time, which is a time which isless than or equal to every timestamp in this encoded record

[0491] 4 bytes offset of agent descriptor section

[0492] 4 bytes indicating number of agent descriptors

[0493] 4 bytes offset of type map section

[0494] 4 bytes indicating number of type map entries

[0495] 4 bytes offset to first transaction record

[0496] 4 bytes size of this file, or 0×FFFFFFFF if unknown.

[0497] 4 bytes 1's complement checksum of this file or 0×FFFFFFFF ifunknown

[0498] The agent descriptor section is used to store a possibly nulllist of agent descriptors that are configured into the network monitorat encoding time. The agent descriptors are strings that plug into aparticular policy language policy. They indicate the location of thesubject monitor in the subject network wiring structure, enabling rulesthat apply to such location in the network and disable rules that do notapply.

[0499] A preferred agent descriptor section comprises an array, whereeach element of the array is an ASCII string, preceded by a single bytegiving its length. The size of the array is given in the header citedabove.

[0500] The preferred type map section is used to improve maintainabilityof the full policy monitoring system. Provided by the type map sectionis a mapping between update types used in an encoded record and theupdate types' string names. The decoding module uses this information todetect new update types that are not supported by mapping known updatesto the correct values. That is, because new update types typically arenot interpretable by old software, they are therefore successfullyskipped.

[0501] A preferred type map section comprises an array, where eachelement of the array contains a four-byte type value, a single byte ofstring length, and the ASCII name of the type. The size of the array isgiven in the header cited above.

[0502] The preferred encoded transactions comprise an array ofindividual update encodings. The size of the array is either derivablefrom the header file size information, or is unbounded, such as, forreal-time monitoring.

[0503] A preferred header for an individual update has the followingformat:

[0504] 1 byte, giving the update type

[0505] 4 bytes, giving the size of this header in bytes, not includingthe length of the header

[0506] 8 bytes (struct timeval) giving the absolute time when thisupdate occurred

[0507] 4 bytes, giving the packet number of this update since themonitor started (first packet=packet #0)

[0508] 4 bytes, giving the eventID of this update, which is the numberof BEGIN_TRANS updates that occurred before this one, since the monitorstarted

[0509] Following the header a body contains additionalupdate-type-specific data, or possibly none.

[0510] To understand all events that transpire on a connection, it isnecessary to combine events of different protocol layers. For example,an update, named SM_IP_ASSOCIATION, provides IP src and dst addressesand establishes a peer relationship. Subsequent events assume that thisinformation is known and builds on it. For example, an update namedICMP_ECHO has no body at all.

[0511] An example of a set of update types and corresponding encodingbody for each update, according to the invention is given below in TableO. The meaning of the term “string” is: if length(string) is<255, thenbyte[length], byte[string][length], else byte[0×ff], byte[a], byte[b],byte[c], byte[d], byte[string][length] where a, b, c, d are the four(big-endian) bytes of length.

TABLE P Evaluation Algorithm In the preferred embodiment the policyengine applies a policy evaluation algorithm to each incoming protocolevent. The algorithm results in a selection of a policy rule applicableto the protocol event and may produce an immediate or final disposition.Following is a step-by-step description of the evaluation algorithmaccording to the preferred embodiment. It is noted that the evaluationprocedure described herein below is in conceptual form and does not takeinto account any possible runtime optimizations: 1) Select a set ofrules applicable to an Agent reporting an event; 2) From said set,select a second set of rules applicable to an associated examinedprotocol. 3) From said second set, select a third set of rulesapplicable to an associated examined protocol action. 4) Starting with amost specific policy rule in said third set and descending to a leastspecific rule find a policy rule satisfied by said protocol event. Amatching algorithm according to the preferred embodiment is as follows:a) If one or more orderly listed prerequisite rules are specified,ensure at least one of said prerequisite rules is satisfied by apreviously processed protocol event. In the preferred embodiment aprerequisite rule is satisfied if it is a pending policy rule for theprotocol event. b) Match initiator and target credentials in the policyrule against the corresponding initiator and target credentialspresented in the protocol event. 5) If a policy rule satisfying theprotocol event is not found the policy engine generates a dispositionfor the network event indicating that a policy specification error wasencountered. Effectively the processing of the network event therebyterminates. 6) If a policy rule satisfying the protocol event is found,the policy engine checks for other rules having a same ranking numberand also satisfying the event. If such rules are found the policy engineuses the following algorithm in the preferred embodiment to select asingle applicable rule: a) Rules that specify all protocols, i.e. usingignore or present, are less specific than rules that explicitly list aset of one or more protocols. b) Rules that specify all actions (i.e.using ignore or present) are less specific than rules that explicitlylist a set of one or more actions. c) Rules that have prerequisites aremore specific than rules that do not have prerequisites. Rules thatspecify a higher-ranking prerequisite are more specific than rules thatspecify a lower-ranking prerequisite. In the preferred embodiment aranking relationship is relevant only if both prerequisite rules belongto a same protocol-action group. d) If thereafter a single rule isdetermined as more specific than the others it is selected for theprotocol event. If more than one rule remains the policy engine sortsthe remaining rules in increasing lexical order by name and selects afirst rule from the sorted rules having an immediate dispositionindicating in decreasing order of precedence: i) a policy violation (anydisposition code other than OK or CONTINUE); ii) CONTINUE (allows otherrules to examine further the network event); and iii) OK The outcome ofthe policy evaluation algorithm herein above is a policy rule thatsatisfies the protocol event. If an immediate outcome is specified forthat rule, it is executed, producing a disposition for the protocolevent. If the disposition comprises final disposition code (any codeother than CONTINUE), the disposition is also the final disposition forthe network event. Otherwise in the preferred embodiment the selectedpolicy rule is a pending policy rule for the network event. In absenceof any further protocol events the pending policy rule is promoted toselected policy rule. A final outcome of the selected policy rule isexecuted producing a final disposition for the network event.

An Exemplary User Interface for Providing and Reporting Processed andAnalyzed Network Data to an End User

[0512] An exemplary user interface for providing and reporting theprocessed and analyzed network data from the database (FIG. 1a-165) toan end user is provided below.

[0513] It should be appreciated that examples of a typical end userusing such interface are, but are not limited to a customer whosenetwork is being monitored, an operations analyst reviewing thecustomer's network environment and network data, and/or a policy analystreviewing the network data and its conformance to network policy.

[0514] The preferred embodiment of the invention uses a web pageparadigm as an example of a type of user interface, and is describedwith reference to figures of screen prints of web pages herein. Whilethe claimed invention herein has disclosed a web page implementation ofa user interface, it will be appreciated by those skilled in the artthat such user interface readily encompasses any form, that can besubstituted therefore to effect a similar result as is achieved by theweb page, including but not limited to any graphical user interface ornon-graphical user interface.

[0515] The preferred embodiment of the invention is described withreference to FIG. 20 and comprises a system dashboard, label 20000 on ahome page, wherein the dashboard 20000 is kept up to date with currentmonitoring information from the monitored network.

[0516] In the preferred embodiment of the invention, the dashboard 20000updates once every five minutes. It should be appreciated that differentupdate rates can be used to keep the data on the dashboard 20000current, and that parts of the underlying customer data may be updatedat a different, such as a slower rate.

[0517] The preferred embodiment of the invention provides a tear offfeature on the system dashboard 20000. In this example, the end userclicks on a tear off tab 20010 to open a tear off console window. FIG.21 shows an example of a tear off console window according to theinvention. It is intended that the end user keep the console window openon the computer desktop all day long to view high level reporting of thehealth of the monitored network.

[0518] The preferred embodiment of the invention provides an outstandingalerts area 20020 of the dashboard and consists of a FIFO queue ofCRITICAL alerts that have been generated by the policy monitoring system(FIG. 1a-106). In the preferred embodiment of the invention thefollowing applies. The size of the alert list can be limited to apredetermined number of elements. The total number of open alerts can bedisplayed within the alerts area 20030.

[0519] The underlying data is updated on a real-time basis. Entries inthe list link to alert details, as depicted in FIG. 28. In this example,clicking on an entry in the list 20030 opens up an alert details page2801 for that particular alert, comprising such alert details as, forexample rule, disposition, time of alert, type of alert, sourceip-address, destination IP-address, and the like.

[0520] The preferred embodiment of the invention provides a healthmonitor 20040 to show a visual representation of the severity categoriesinto which the current observed traffic has been assigned over apredetermined amount of time. In this example, the underlying data isupdated every five minutes and summarizes traffic over the last one hourand last twenty four hour periods. CRITICAL and HIGH severity alertshave a red bar 20050, MEDIUM, WARNING and MONITOR uses a yellow bar20060, and all others are green 20070.

[0521] The preferred embodiment of the invention provides access tocurrent summary reports. An example is shown in FIG. 20 as part of theend user's home page. Such screen allows the end user to generatequeries that summarize report data filtered by the monitoring point andover configurable time periods. An interface feature, such as a dropdownlistbox 20090 allows the end user to choose one of a predetermined setof time periods, such as but not limited to the following:

[0522] Select date range—A specific time period expressed in startingmonth, day and hour, followed by ending month, day and hour using aninterface feature such as dropdown listboxes 20091;

[0523] Last two hours;

[0524] Last 24 hours;

[0525] Today (since midnight);

[0526] Yesterday (00:00-23:59:59);

[0527] Last seven days;

[0528] This month (from first to present);

[0529] Last month (from first to end of month);

[0530] Last three months (three months back from present); and

[0531] Custom (retrieves date/time range from the last manuallyconfigured query).

[0532] The preferred embodiment of the invention provides an eventssummary view as shown in FIG. 22.

[0533] In the example shown in FIG. 22, viewing the summary for aspecific time period displays both a chart 2201 of a predeterminednumber of columns and a table 2202 displaying the following information,when the conformance tab 2203, the violators tab 2204, or the targetstab 2205, respectively, is selected:

[0534] A conformance chart/table shown in FIG. 22, displaying the countof violations for each rule/disposition pair.

[0535] An icon 2206 links to a network event details page, such as shownin FIG. 23 that contains details of events that make up this count, i.e.all network events with such rule/disposition pair that occurred in thegiven time period.

[0536] A violators chart 2901 and table 2902 shown in FIG. 29,displaying the count 2903 of the number of violations for each of thetop violating ip-addresses 2904.

[0537] An icon 2206 links to a network event details page, such as shownin FIG. 23 that contains details of events that make up this count, i.e.all network events with such originating ip-address that occurred in thegiven time period.

[0538] A targets chart 3001 and table 3002 shown in FIG. 30, displayingthe count 3003 of the number of violations for each of the topdestination IP-addresses 3004.

[0539] An icon 2206 links to the a event details page, such as shown inFIG. 23 that contains details of events that make up this count, i.e.all network events with such destination IP-address and port thatoccurred in the given time period.

[0540]FIG. 22 shows the events summary report for conformance.

[0541] The preferred embodiment of the invention provides a link tonetwork events detail information. In this example, a separate link 2206builds a network events details page as shown in FIG. 23. FIG. 23contains a table that may be sorted or reverse sorted by any of thecolumns displayed 2301 of all violating network events with such arule/disposition pair that occurred in the chosen time period.

[0542] In the preferred embodiment of the invention, the summary page(FIG. 22) contains a specification of the date range of the data beingdisplayed. In particular, if the start of the range falls outside therange of date for acquiring user data then the actual start date of theuser data is displayed.

[0543] It should be appreciated that in another equally preferredembodiment, user defined and configurable query and reports settings canbe stored, for example, in a user's preferences or profile.

[0544] The preferred embodiment of the invention comprises trend reportson the dashboard, wherein such reports comprise charts that link to anetwork events summary page containing details of the summarizedtraffic. More specifically, the charts, unless otherwise explicitlyspecified, are bar charts, each of which link to the network eventssummary page.

[0545] Referring to FIG. 20, the preferred embodiment of the inventioncomprises a section, such as a QuickWeek section 20100 of the end user'smain page, such as a login page or home page that contains trend graphs,such as but not limited to the following:

[0546] During the past seven days, the five most frequentrule/disposition combinations versus count 20110;

[0547] During the past seven days, the five most frequent violatorip-addresses versus count 20120; and

[0548] During the past seven days, the five most frequent targetip-addresses versus count 20130.

[0549] It should be appreciated that another equally preferredembodiment of the invention comprises an input means for the end user tocustomize which trends appear in the trend, e.g. QuickWeek section, andto customize the time period being viewed.

[0550] The preferred embodiment of the invention comprises trend chartsthat are embedded into details pages. Each of the trend charts allowsthe end user to dynamically configure a time range by a means such as apull down menu. Examples of such embedded trend charts are:

[0551] Policy effectiveness;

[0552] Number of policy changes over time;

[0553] Event Summary (such as for the following):

[0554] Conformance: Graphical view of the data for the specified timeperiod 2201;

[0555] Violators: Graphical view of the data for the specified timeperiod; and

[0556] Targets: Graphical view of the data for the specified timeperiod; and

[0557] Network Event Details (such as for the following):

[0558] Conformance Event Details (FIG. 23): Violator count over time fora particular rule/disposition combination 2303;

[0559] Violators Event Details: Conformance count over time for aparticular violator; and

[0560] Target Event Details: Conformance count over time for aparticular target;

[0561] All, e.g. in chronological order: Conformance count over time fora particular time period.

[0562] The preferred embodiment of the invention provides event detailreports, such as for but not limited to network event details, protocolevent details, and alert details, described below.

[0563] The preferred embodiment of the invention provides a networkevent details page containing listed fields in columns that varyaccording to the violation type, such as, for example, All, Conformance(FIG. 23), Violator, and Target that had been selected at the summarylevel. For each type, except All, rather than repeat the field orcolumn(s) which reiterate the violation, it will be displayed in theheading of the events detail page. For example, after choosing to viewevent details for a particular target, the DstIP is not repeated inevery row. Each of the columns may be used to sort or reverse sort thereport by clicking on that column's heading name. Following is a list oftypes of data provided in a network event details page:

[0564] Monitoring Point;

[0565] Disposition Name;

[0566] Rule Name;

[0567] Disposition Code;

[0568] Severity;

[0569] Src IP;

[0570] Src Port;

[0571] Dst IP;

[0572] Dst Port;

[0573] IPProtocol;

[0574] Event Time: event times can be stored throughout the system inUTC; and

[0575] Application Data:

[0576] ICMP-ICMP action code;

[0577] HTTP-URL;

[0578] FTP-Filename;

[0579] SSL-Ciphersuite, Issuer and Subject's certificate CommonName,Certificate Status;

[0580] SSH-Authentication handshake status; and

[0581] Application Status Code

[0582] HTTP-StatusCode.

[0583] The preferred embodiment of the invention provides a protocolevent details page as depicted in FIG. 24 and that is created in thecontext of a particular network event instance. This data is retrievedon an as-needed basis from a database. The content of this page reflectsthe data available in a protocol event view of the QueryTool and isspecific to the protocol or protocols being displayed. Such dataincludes, but is not limited to:

[0584] Data from such attributes as IP address, interface address,protocol ID, service port, URL, file pathname, user name, passwordmetrics, public key certificate, encrypted session parameters and statuscodes; and

[0585] Protocol-specific actions such as HTTP methods, TCP protocolmessages, ICMP message codes, FTP control commands, and authenticationsteps.

[0586] The preferred embodiment of the invention provides an alert eventdetails page as depicted in FIG. 28 containing, but not limited to thefollowing:

[0587] details of the network event that caused the alert;

[0588] rule and disposition name that triggered alert;

[0589] log comment from the disposition;

[0590] time at which the alert was generated;

[0591] initiator ip address of the corresponding non-conformant traffic;

[0592] target ip address of the corresponding non-conformant traffic;

[0593] an icon that links to the network event details page describingthe non-conformant network event; and

[0594] checkbox to clear the alert.

[0595] The preferred embodiment of the invention provides a policyupdate page containing, but not limited to a table displaying each timea new policy is installed on the security policy management systemdiscussed herein. This table contains, but is not limited to:

[0596] Date of the policy installation;

[0597] Description of policy; and

[0598] A link to the English description that represents the newlyinstalled policy.

[0599] It should be appreciated that in the preferred embodiment of theinvention alerts are generated whenever a disposition with a CRITICALseverity is assigned to a network event, each alert generating an emailcontaining, but not limited to the following information:

[0600] time the alert occurred;

[0601] rule and disposition name that triggered alert;

[0602] log description, if any, from the corresponding disposition;

[0603] initiator ip address of the corresponding non-conformant traffic;

[0604] target ip address of the corresponding non-conformant traffic;and

[0605] link to the network event detail describing the non-conformantnetwork event.

[0606] The preferred embodiment of the invention provides a customerpage that allows the user to configure a list of email addresses withina customer's organization that shall receive alert email.

[0607] Another equally preferred embodiment provides means for accessingad-hoc queries for the end user, such as, but not limited to, filteringresults by any one or all of the following:

[0608] Protocol of the rule name;

[0609] Policy rule name;

[0610] ∘ A regular expression within the rule name;

[0611] Disposition name of the violation;

[0612] ∘ A regular expression within the disposition name;

[0613] Source ip-address;

[0614] ∘ A regular expression with source ip-address;

[0615] Target (Destination) ip-address;

[0616] ∘ A regular expression within target (destination) ip-address;

[0617] Target (destination) port; and

[0618] ∘ A regular expression within target (destination) port.

[0619] An example of a means for accessing ad-hoc queries is an advancedsearch feature, such as for example, an advanced search dialog box 3100,as depicted in FIG. 31. In the preferred embodiment of the invention,the advanced search dialog box 3100 comprises list boxes for suchcategories, such as protocol 3101, rule 3102, and disposition 3103, andtext boxes for descriptions, such as regular expression in a rule 3104or disposition 3105 and IP-addresses 3106.

[0620] In the preferred embodiment of the invention, an end user canopen the advanced search dialog box 3100 from an Advanced Search link3201 on the dashboard, as depicted in FIG. 32, or from any event summaryor event details page.

[0621] The preferred embodiment of the invention provides informationalaids. For example, the following information about a user's policy isavailable via a variety of features, such as but not limited to links,tool tips, and the like:

[0622] Customer specific policy interpretation, such as provided byEnglish language representation;

[0623] Rule and disposition descriptions as defined by the user in theuser's policy, resolved DNS names for ip-addresses, and TCP and UDPservice names; and

[0624] A copyright page containing copyrights and trademarks as requiredby licensing agreements with vendors.

[0625] The preferred embodiment provides links to descriptions of rules,dispositions, IP-addresses, and the like, displayed, for example in apop up window whenever the user's cursor is over the respective field,as depicted in FIG. 22 2207, FIG. 23-2302, FIG. 25-2501, FIG. 26-2601,and FIG. 27-2701, respectively.

[0626] The preferred embodiment of the invention provides links on eachpage that include, but are not limited to:

[0627] Context sensitive help per-page.

[0628] In the preferred embodiment of the invention, each details pagecontains a button linking to a printer friendly version of the page.

[0629] In the preferred embodiment of the invention, regardless of thetime zone the user's or the policy monitoring systems runs on, such as,for example Universal Time Coordinates (UTC). Any time being displayedto the user, such as, for example, on a website or in contents ofemails, is converted to the user's time zone and as such is explicitlydisplayed.

[0630] Although the invention has been described in detail withreference to particular preferred embodiments, persons possessingordinary skill in the art to which this invention pertains willappreciate that various modifications and enhancements may be madewithout departing from the spirit and scope of the claims that follow.

1. A method for allowing comprehension of a network security policyspecification for a network by generating a human languagerepresentation of said policy, said specification having a textrepresentation, said method comprising: loading said text representationof said policy specification into a parser; said parser looping throughall protocols, wherein said looped protocols are supported in saidpolicy specification, said supported protocols having actions, and saidsupported protocols having associated rules; for each supportedprotocol, sorting said rules in order of rank; looping in ranked orderthrough said sorted rules; for each rule, generating a text descriptionof said each rule; and if said text description not first generated textdescription, then appending said text description to a collection ofalready generated descriptions, else, creating said collection ofalready generated descriptions with said text description.
 2. The methodof claim 1, wherein said language is any of English, French, German,Spanish, Italian, Japanese, Chinese, and Korean.
 3. The method of claim1, wherein looping through all protocols is from highest protocol levelto lowest protocol level.
 4. The method of claim 1, wherein ranked orderof sorted rules is from highest rank to lowest rank.
 5. The method ofclaim 1, further comprising: providing an HTML flag; and formatting saidtext description into an HTML table when said HTML flag is set.
 6. Themethod of claim 1, wherein generating said text description of said eachrule uses an algorithm.
 7. The method of claim 6, wherein for said eachrule said text description generating algorithm comprising: outputting aname of said each rule; outputting a name of an agent, wherein saidagent is a network monitor on said network; looping through allcombinations of said protocol and said actions; for each action, if saidaction is ignored, then applying said each rule to an entirety of saidprotocol, else applying said each rule to some or all of said actions;evaluating an immediate outcome of said each rule; outputting a firstdisposition corresponding to said immediate outcome; outputtingconditions on said first disposition, if any said conditions exist;evaluating a final outcome of said each rule; outputting a seconddisposition corresponding to said final outcome; outputting conditionson said second disposition, if any said conditions exist; if said eachrule applies to a target and/or initiator, outputting name(s) of saidtarget and/or initiator, else outputting a term representing any entity;and outputting prerequisites, if any exist.
 8. A system for allowingcomprehension of a network security policy specification for a networkby generating a language representation of said policy, saidspecification having a text representation, said system comprising:means for loading said text representation of said policy specificationinto a parser; means for said parser looping through all protocols,wherein said looped protocols are supported in said policyspecification, said supported protocols having actions, and saidsupported protocols having associated rules; for each supportedprotocol, means for sorting said rules in order of rank; means forlooping in ranked order through said sorted rules; for each rule, meansfor generating a text description of said each rule; and means for ifsaid text description not first generated text description, thenappending said text description to a collection of already generateddescriptions, else, creating said collection of already generateddescriptions with said text description.
 9. The system of claim 8,wherein said language is English.
 10. The system of claim 8, whereinmeans for looping through all protocols is from highest protocol levelto lowest protocol level.
 11. The system of claim 8, wherein rankedorder of sorted rules is from highest rank to lowest rank.
 12. Thesystem of claim 8, further comprising: means for providing an HTML flag;and means for formatting said text description into an HTML table whensaid HTML flag is set.
 13. The system of claim 8, wherein means forgenerating said text description of said each rule uses an algorithm.14. The system of claim 13, wherein for said each rule said textdescription generating algorithm comprising: means for outputting a nameof said each rule; means for outputting a name of an agent, wherein saidagent is a network monitor on said network; means for looping throughall combinations of said protocol and said actions; for each action, ifsaid action is ignored, means for applying said each rule to an entiretyof said protocol, else applying said each rule to some or all of saidactions; means for evaluating an immediate outcome of said each rule;means for outputting a first disposition corresponding to said immediateoutcome; means for outputting conditions on said first disposition, ifany said conditions exist; means for evaluating a final outcome of saideach rule; means for outputting a second disposition corresponding tosaid final outcome; means for outputting conditions on said seconddisposition, if any said conditions exist; if said each rule applies toa target and/or initiator, means for outputting name(s) of said targetand/or initiator, else outputting a term representing any entity; andmeans for outputting prerequisites, if any exist.
 15. A method forgenerating a text description of a policy rule of a network securitypolicy specification for a network, said rule associated with a protocoland actions, said method comprising: outputting a name of said rule;outputting a name of an agent, wherein said agent is a network monitoron said network; looping through all combinations of said protocol andsaid actions; for each action, if said action is ignored, then applyingsaid rule to entirety of said protocol, else applying said rule to someor all of said actions; evaluating an immediate outcome of said rule;outputting a first disposition corresponding to said immediate outcome;outputting conditions on said first disposition, if any said conditionsexist; evaluating a final outcome of said rule; outputting a seconddisposition corresponding to said final outcome; outputting conditionson said second disposition, if any said conditions exist; if said ruleapplies to a target and/or initiator, outputting name(s) of said targetand/or initiator, else outputting a term representing any entity; andoutputting prerequisites, in any exist.
 16. A system for generating atext description of a policy rule of a network security policyspecification for a network, said rule associated with a protocol andactions, said system comprising: means for outputting a name of saidrule; means for outputting a name of an agent, wherein said agent is anetwork monitor on said network; means for looping through allcombinations of said protocol and said actions; for each action, if saidaction is ignored, means for applying said rule to entirety of saidprotocol, else applying said rule to some or all of said actions; meansfor evaluating an immediate outcome of said rule; means for outputting afirst disposition corresponding to said immediate outcome; means foroutputting conditions on said first disposition, if any said conditionsexist; means for evaluating a final outcome of said rule; means foroutputting a second disposition corresponding to said final outcome;means for outputting conditions on said second disposition, if any saidconditions exist; if said rule applies to a target and/or initiator,means for outputting name(s) of said target and/or initiator, elseoutputting a term representing any entity; and means for outputtingprerequisites, in any exist.